-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Give to Typical Price his own structure ? #39
Comments
If I got your idea, in the example you provide I think it got only 20% from the 3rd pros. fn calc(input: &CommodityChannelIndexInput) -> Self::Output {
(input.tp - input.sma) / (input.mad * 0.015)
} Here you have some kind of special Input for CCI, that brings all tp, sma and mad already precalculated? |
The idea is to create a new structure which can take the ownership of some indicators. Here is a dirty example (cannot work like that) : group.add(keltner_channel);
group.add(percentage_price_oscillator);
group.next(&dt); In this example, both Keltner Channel and Percentage Price Oscillator use an Exponential Moving Average so if both indicators have the same period, it is safe to only calculated one EMA. The group take care of the order of execution so when we will call pub trait Next<T> {
type Output;
fn next(&mut self, input: T) -> Self::Output; // <= update the indicator if needed, then call `Calc`
}
pub trait Calc {
type Input;
type Output;
fn calc(input: Self::Input) -> Self::Output; // <= stateless, only apply the formula
} I also mention another advantage of the group but it will be harder to implement and maybe less clean.
But we may need n stacks depending of the indicators :
Here, ER and RoC can share their stack but not MFI - even if MFI can share his stack with others MFIs running on a different period. |
More and more indicators starts to use the typical price.
Does it have any sense to create a structure
TypicalPrice
which will implementNext
?We will (for example) be able to change:
to:
Pros:
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: calling
Next
on the group runCalc
for each indicator.Calc
takes all the parameters and only apply the formula of the indicator (so TP, MAD(20), MAD(x), etc, cannot be processed twice):Cons:
The text was updated successfully, but these errors were encountered: