Is your feature request related to a problem? Please describe.
Not a problem, but more of a feature request that I'm happy to write a PR for.
Describe the solution you'd like
Would like the ability to pass a configuration option object for every indicator. This configuration object would respect existing default values in each indicator.
Note that I didn't pass a signal, but I did pass a non-default fast and slow ema value. Each function would fallback to default options if they're not explicitly passed.
I can imagine that for some functions, particularly those that utilize a period, that there could be some breaking changes due to argument order. However, this approach is far more flexible long term. We can always provide depreciation flags for affected methods. For example...
Note as well that this configuration can also be undefined, in which case the default values are used.
Since this would introduce a breaking change, we can support both the old and new argument order, but provide a deprecation message for the old argument order.
Describe alternatives you've considered
The only way around this is to create custom indicators, or build off of existing ones. While this does work, it just isn't terribly flexible. And such parameters are regularly changed in production trading systems anyhow. This deserves to be a first-class feature.
Additional context
I'm going to build a trading system using this library and intend to make a series of changes, such as this. I'm happy to push those changes upstream, if desired, or maintain my own fork, if not desired. One other change I'm considering is shipping backtest statistics such as win and loss %, sharpe ratio, alpha, beta, etc. Let me know if you'd like a PR for this as well.
This library has a fantastic base of functionality, but it's missing a few features I'd expect to have in a production system. I'm happy to work with you on some sort of a middle ground on this and other issues!
Is your feature request related to a problem? Please describe. Not a problem, but more of a feature request that I'm happy to write a PR for.
Describe the solution you'd like Would like the ability to pass a configuration option object for every indicator. This configuration object would respect existing default values in each indicator.
Before:
macd(closings)After:macd(closings, { fast: 6, slow, 12 })Note that I didn't pass a
signal, but I did pass a non-defaultfastandslowema value. Each function would fallback to default options if they're not explicitly passed.I can imagine that for some functions, particularly those that utilize a
period, that there could be some breaking changes due to argument order. However, this approach is far more flexible long term. We can always provide depreciation flags for affected methods. For example...Before:
ema(period, values)After:ema(values, { period: 200 })Note as well that this configuration can also be
undefined, in which case the default values are used.Since this would introduce a breaking change, we can support both the old and new argument order, but provide a deprecation message for the old argument order.
Describe alternatives you've considered The only way around this is to create custom indicators, or build off of existing ones. While this does work, it just isn't terribly flexible. And such parameters are regularly changed in production trading systems anyhow. This deserves to be a first-class feature.
Additional context I'm going to build a trading system using this library and intend to make a series of changes, such as this. I'm happy to push those changes upstream, if desired, or maintain my own fork, if not desired. One other change I'm considering is shipping backtest statistics such as win and loss %, sharpe ratio, alpha, beta, etc. Let me know if you'd like a PR for this as well.
This library has a fantastic base of functionality, but it's missing a few features I'd expect to have in a production system. I'm happy to work with you on some sort of a middle ground on this and other issues!