Indicators: ColorZerolagMomentumOSMA

 

ColorZerolagMomentumOSMA:

Smoothed ColorZerolagMomentum indicator rate of change, represented as a colored histogram, allows you to determine the current trend direction quite accurately.

Fig.1. ColorZerolagMomentumOSMA

Author: Nikolay Kositsin

[Deleted]  

Hello, I would like to discuss this point. You have a check in this indicator:

if(BarsCalculated(Momentum1_Handle)<rates_total
      || BarsCalculated(Momentum2_Handle)<rates_total
      || BarsCalculated(Momentum3_Handle)<rates_total
      || BarsCalculated(Momentum4_Handle)<rates_total
      || BarsCalculated(Momentum5_Handle)<rates_total
      || rates_total<min_rates_total)
      return(0);

It turns out that if the number of bars on one of the used indicators is less than rates_total, the indicator will be recalculated completely (because return(0)). Wouldn't it be better to put all the checks for equality with rates_total separately and, in case of non-matching, return(prev_calculated)? Because then only the last bar will be recalculated (when BarsCalculated() == rates_total) and not the whole history.

Thanks in advance for the answer.

 
Tapochun:

Hello, I would like to discuss this point. In this indicator you have a check:

It turns out that if the number of bars on one of the used indicators is less than rates_total, the indicator will be recalculated completely (because return(0)). Wouldn't it be better to put all the checks for equality with rates_total separately and, in case of non-matching, return(prev_calculated)? Because then only the last bar will be recalculated (when BarsCalculated() == rates_total) and not the whole history.

Thank you in advance for your answer.

Yes, in principle, your logic is quite reasonable. I tried to do it this way once, but something didn't work out, but I don't remember exactly what it was. I only remember that I caught the indicator in this code variant on some glitch and decided to leave it as it was.