Give to Typical Price his own structure ? #39
Description
More and more indicators starts to use the typical price.
Does it have any sense to create a structure TypicalPrice which will implement Next?
We will (for example) be able to change:
impl<T: Close + High + Low> Next<&T> for CommodityChannelIndex {
type Output = f64;
fn next(&mut self, input: &T) -> Self::Output {
let tp = (input.close() + input.high() + input.low()) / 3.0; // <--- before
let sma = self.sma.next(tp);
let mad = self.mad.next(input);
if mad == 0.0 {
return 0.0;
}
(tp - sma) / (mad * 0.015)
}
}to:
impl<T: Close + High + Low> Next<&T> for CommodityChannelIndex {
type Output = f64;
fn next(&mut self, input: &T) -> Self::Output {
let tp = self.tp.next(input); // <--- after
let sma = self.sma.next(tp);
let mad = self.mad.next(input);
if mad == 0.0 {
return 0.0;
}
(tp - sma) / (mad * 0.015)
}
}Pros:
- The crate provide a new indicator.
- We exclude even more logic from our current indicators.
- Let's imagine a future where our indicators can share a stack, so we do not allocate one
deque: Box<[f64]>per indicator but only ones with the length of the longest period. Putting TP inside an indicator can offer even more optimization for our "group of indicators" like calculating it only ones and sharing his value across all the group.
Idea: callingNexton the group runCalcfor each indicator.Calctakes all the parameters and only apply the formula of the indicator (so TP, MAD(20), MAD(x), etc, cannot be processed twice):
fn calc(input: &CommodityChannelIndexInput) -> Self::Output {
(input.tp - input.sma) / (input.mad * 0.015)
}Cons:
- This is a one-liner...