Implement strategies #1
Conversation
| #[derive(Clone, Copy)] | ||
| #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))] | ||
| pub struct IndicatorResult { | ||
| signals: [Action; IndicatorResult::SIZE], |
There was a problem hiding this comment.
Removing signals from Indicator result
| } | ||
|
|
||
| impl IndicatorResult { | ||
| /// Size of pre-allocated result array | ||
| /// For the most of cases it should not be used anywhere outside this crate | ||
| pub const SIZE: usize = 4; | ||
|
|
||
| /// Returns a slice of signals of current indicator result | ||
| #[must_use] |
There was a problem hiding this comment.
Removing all signal related methods
| @@ -0,0 +1,131 @@ | |||
| use crate::core::{ValueType, IndicatorResult, Action, Error, OHLCV}; | |||
There was a problem hiding this comment.
Contains all strategy related traits. Mostly copied from indicator traits. Can be optimized
| #[inline] | ||
| #[must_use] | ||
| pub fn value(&self, index: usize) -> ValueType { | ||
| self.indicator_result.value(index) |
There was a problem hiding this comment.
Delegate to indicator value.
| @@ -0,0 +1,56 @@ | |||
| use crate::core::{PeriodType, StrategyConfig, OHLCV, Error, StrategyInstance, IndicatorConfig, Source, StrategyResult, Action, IndicatorInstanceDyn}; | |||
There was a problem hiding this comment.
A composite strategy that uses HMA & Pivot Reversal indicators
| @@ -0,0 +1,55 @@ | |||
| use crate::core::{PeriodType, StrategyConfig, OHLCV, Error, StrategyInstance, IndicatorConfig, Source, StrategyResult, Action, IndicatorInstanceDyn}; | |||
There was a problem hiding this comment.
A composite strategy that uses HMA & EMA indicators
|
I don't see any reason for removing signals from the indicators. Indicators values itself doesn't make sense. We always need to interpret it somehow. On the other hand, strategies should receive indicators signals and then proceed a final action for trader. That might be not only simple "Sell" or "Buy", but something more complex like "stop limit" or "trailing stop", or something else. |
|
Ok, I think a little bit more about your idea and changed my decision. According to my benchmarks processing signals may take up to 50% of the indicator's performance. So, yes, if you as developer don't like current signals implementation of some indicator, you starting to waste performance to calculate those useless signals. |
This PR extracts signals from indicators and introduces strategies to capture signals
The build at the moment fails because not all indicators are updated to return only values