Zigzag NRP on oscillator: counter since last "zig" error (not repainting)

[MisterH]

Hi guys.

This is a question for people familiar with the Zig-Zag indicator. It's pretty old, but has its use.

Multiple changes were made to the standard indicator, turning it into a custom indicator (hereby attached called "#BarsSinceLastZigZag_MOD2"):

• Instead of using High & Low of a bar, only the Close is taken into account, so the 3 standard parameters (Depth, Deviation, Backstep) are replaced by 1 (Length: size of the window).
• It was made 'non-repainting', as in: the last leg is drawn with delay, so it does not change its shape when price changes (search "ZIG ZAG NRP" on this website), only after a reverse move large enough is made by the close price, the next leg appears. So it only draws the line after completion; no repainting, but obviously a little slow (1 "reverse move" delay).
• Instead of calculating it on the close, all this is calculated on a (single-line) oscillator (custom indicator: 1 of the elements of the RMO: "Rahul Mohindar Oscillator")
• A counter was installed: it counts the number of bars since the last completed (non-repainting) zigzag on the oscillator, with a special property: when the oscillator is on a declining segment, and it retraces back upwards a little, the counter goes flat. When the oscillator reaches a new low (since the previous low on the segment), the count is picked up again to the same level as if it would have been if it hadn't retraced (& vice versa). Logically, every new NRP-zigzag segment on the oscillator happens while the counter line is flat.

"Why is this usefull", I hear you think? Well, it can serve as an input for the window length to calculate another indicator over. Comparable to other techniques proposed in Mladen's "Adaptive lookback indicators" thread.

However, there is still a small glitch in the code: it's not a repainting issue (doesn't use bars from "the future" to calculate the present), but there is a fault in the logic somewhere: when a new segment of the NRP zigzag on the oscillator is about to appear, so a reverse move in the oscillator has started, and the counter goes flat, and then after that, the reverse move continues far enough for the new leg of the NRP zigzag to appear, the counter's "reset point" flips back to the point of the end of the new zigzag leg, and it doesn't show the "flat" part of the counter anymore. I refer to the attached image: It's an M1 chart to check its operation in real-time with SMA(1) on the indicators: IMHO this is more reliable than doing a visual-mode tick-chart back-test with an empty EA, when looking for logic-errors or causality faults (aka repainting).

So in the image:

• First panel: the counter of the # bars since the last point of the last NRP zigzag leg (Aqua), and an SMA(1) calculated on this counter (Red): this shows the mistake: the difference between the Aqua and the Red lines: red is correct, Aqua is incorrectly "reset".
• Second panel: the oscillator (Gray), with the zigzag NRP (Aqua)

For the counter (first panel), if you compare the red line with the aqua line, it can be seen that at every switch of direction, the counter is reset, back to the point when the new leg appeared, while the real-time shape (red line), should be the shape that is shown, also historically, when the indicator is initially dropped on the chart.

I don't think an end-point transform is the best solution, there is a simple logical fault that I'm not seeing.

If you have time, please check the attached mq4's: any suggestion is appreciated.

Thank you.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

P.S.: ChatGPT about zigzag:

Depth: This parameter specifies the minimum number of price fluctuations required to form a swing high or low. 

A swing high is formed when the current price is higher than the previous high and the number of bars between  

them is equal to or greater than the Depth value. A swing low is formed when the current price is lower than 

the previous low and the number of bars between them is equal to or greater than the Depth value.

Deviation: This parameter is used to filter out smaller price movements and focus on larger trends. 

It specifies the percentage by which the price must move in order to form a new swing high or low. A higher 

Deviation value will filter out more small price movements, resulting in fewer swing highs and lows, 

while a lower Deviation value will include more price movements, resulting in more swing highs and lows.

Backstep: This parameter determines how far back the indicator looks for a previous swing high or low. 

It specifies the number of bars that must be examined before a new swing high or low can be formed. A larger 

Backstep value will look further back in time to find a previous swing high or low, resulting in a smoother 

ZigZag line, while a smaller Backstep value will look closer in time and may produce a more choppy ZigZag line.

By adjusting these parameters, traders can customize the ZigZag indicator to suit their trading style and the 

asset they are analyzing. However, it is important to note that the ZigZag indicator should be used in 

combination with other technical indicators and fundamental analysis to make informed trading decisions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -