weird behaviour of zigzag indicator - page 2

New comment
 
Imre Sopp #:

One could argue that zig zag logic is rather complicated. In any case, a logic error occurs in the code if the indicator locks the previous state too early. All zig zag indicators are repaintable in a logical sense, otherwise, they wouldn’t work. The key issue is ensuring that a new extreme is confirmed before locking the previous state.

As debugging is a voluminous task and I won’t delve into the code in detail. But I can provide my own code for reference if needed. This never misses and can be used to harvest data into arrays. there are also explanations and print statements for debugging. Maybe this will help.

this "sec 1_2"...."sec 2_2" stuff really isn't a a proper comment and doesn't make sense to an outside observer. If you're confident about it, why not put a working code on the codebase? You can say something, but nobody will believe what you're saying. I'm sceptical that a few seconds of time will do anything good to confirm a swing

 
Ryan L Johnson #:

If anyone wants a non-repainting ZigZag-ish indicator, see attached. The arrows/alerts are generated when each permanent "square" extremum appears. As is usually the case between repainting and non-repainting variants, you are accepting lag to obtain certainty by using this indicator.

I just backtested this, and it's not bad actually, the lag is acceptable...it isn't that much lag which makes this reasonable

 
Conor Mcnamara #:

I just backtested this, and it's not bad actually, the lag is acceptable...it isn't that much lag which makes this reasonable

Thank you. Truth be told, it's not my logic. No one else could convert the original jumbled up MQL4 code to MQL5 on another forum so I did it at another trader's request. Have you ever seen a programmer write like a human decompiler? I have. Credit to the original file name is in the header. No coder was listed, of course.

 
Conor Mcnamara #:

1: If you're confident about it, why not put a working code on the codebase? You can say something, but nobody will believe what you're saying.

2: I'm sceptical that a few seconds of time will do anything good to confirm a swing 

1:  I'm almost sure it's old code but it's not an indicator, it's the logic of sequencing high and low extremes without messing up the order. Basically it's the same but instead of drawing a line, data is collected. There are many indicators even in the code base...why one more...

2:  it's not about time, this comment is misleading though... since i built it once on top of m1 timeframe to bugfix it i have left comments like this. Think of state management instead of time. these are the points that are of concern for some zigzag algorithms as shown at the beginning of the thread. 

The term "repainting" is a simplification that doesn’t fully capture the technical reality of algorithms like the Zig Zag therefore I used the word repaint in the wrong context and meant the wrong state management. Repainting and false logic are not the same and shouldn’t be confused.

  • For example A static non-repainting (static) zig-zag can lock its last state only once if the two previous states are firmly fixed. If he only looked at the previous state, it would cause overpainting, as the last state would become the previous state if the movement in the same direction continued. This introduces a lag, but is great for data harvesting.
  • Repainting (dynamic) Zig-Zag can adjusts its states in real-time, but he also has to do it only when the threshold necessary to lock the previous state has been exceeded (state is theoretically locked). This is why the zig-zag is inherently lagging. But it's not a bug because it is still faster than static zig-zag and may be  requested because that's more suitable for live trading, specially when optimized using historical data from a static Zig-Zag.
  • However, whether the Zig-Zag is static or dynamic, if a new state is not confirmed (price hasn’t crossed the threshold), the previous state should not be locked. If the state management logic is flawed and a rapid false price movement occurs, the wrong state can accidentally lock. This leads to the issue shown in the original picture, where the indicator behaves unpredictably due to incorrect state locking.
 
Imre Sopp #:
1:  I'm almost sure it's old code but it's not an indicator, it's the logic of sequencing high and low extremes without messing up the order. Basically it's the same but instead of drawing a line, data is collected. There are many indicators even in the code base...why one more...

2:  it's not about time, this comment is misleading though... since i built it once on top of m1 timeframe to bugfix it i have left comments like this. Think of state management instead of time. these are the points that are of concern for some zigzag algorithms as shown at the beginning of the thread. 

The term "repainting" is a simplification that doesn’t fully capture the technical reality of algorithms like the Zig Zag therefore I used the word repaint in the wrong context and meant the wrong state management. Repainting and false logic are not the same and shouldn’t be confused.

  • For example A static non-repainting (static) zig-zag can lock its last state only once if the two previous states are firmly fixed. If he only looked at the previous state, it would cause overpainting, as the last state would become the previous state if the movement in the same direction continued. This introduces a lag, but is great for data harvesting.
  • Repainting (dynamic) Zig-Zag can adjusts its states in real-time, but he also has to do it only when the threshold necessary to lock the previous state has been exceeded (state is theoretically locked). This is why the zig-zag is inherently lagging. But it's not a bug because it is still faster than static zig-zag and may be  requested because that's more suitable for live trading, specially when optimized using historical data from a static Zig-Zag.
  • However, whether the Zig-Zag is static or dynamic, if a new state is not confirmed (price hasn’t crossed the threshold), the previous state should not be locked. If the state management logic is flawed and a rapid false price movement occurs, the wrong state can accidentally lock. This leads to the issue shown in the original picture, where the indicator behaves unpredictably due to incorrect state locking.

I see what you mean. This guy wrote a zigzag for MT4 with similar state management and the code is quite clean:

Code Base

Auto Scale ZigZag

Evgeniy Chumakov, 2024.12.17 13:13

ZigZag with automatic step size detection for changing wave direction.


If you want an MT5 version:

Code Base

Autoscaling Zigzag

Conor Mcnamara, 2025.03.02 22:18

A zigzag indicator that uses a single input to adjust the step size for detecting wave direction changes

Auto Scale ZigZag
Auto Scale ZigZag
  • www.mql5.com
ZigZag with automatic step size detection for changing wave direction.
 
Conor Mcnamara #:

Autoscaling Zigzag

Conor Mcnamara, 2025.03.02 22:18

A zigzag indicator that uses a single input to adjust the step size for detecting wave direction changes

i didn't look at your backround, i didn't need to explain it to You but maybe it's still helpful for those who are still working on it....

zigzag is a super good statistics gathering tool in general...  I once built a data collector and optimiser on top of zig zag logic. A very effective combination. Unfortunately collects statistics only on y axis.

Now with this topic I got interested again, the idea came up to build additional geometric calculation combinations for better statistical analysis but, that's probably off topic already.

 
Imre Sopp #:

i didn't look at your backround, i didn't need to explain it to You but maybe it's still helpful for those who are still working on it....

zigzag is a super good statistics gathering tool in general...  I once built a data collector and optimiser on top of zig zag logic. A very effective combination. Unfortunately collects statistics only on y axis.

Now with this topic I got interested again, the idea came up to build additional geometric calculation combinations for better statistical analysis but, that's probably off topic already.

Maybe consider combining a non-repainting wide set zigzag with a repainting narrow set zigzag. Taking this a bit further, scaling-in based on repaints while non-repaints remain current is possible.💡

 
On the discussion of static zigzag above, I argue that this is in fact suitable for live trading, the non repainting aspect means that you have a direct location for buy or sell signal. The zigzag won't paint too many legs if the period is high for calculation of the extremes. How it becomes useful for entry indication is that a bottom facing leg marks a support area (ideally) letting you know that the next leg HAS to be upwards as part of the structure. It's still not using math, but extremes based on a period are still extremes, which are useful pivot points. This non repainting structure is preferable for some. But the extremes themselves can be invalidated with a break of the market structure. Similarly in donchian channel.
 
Conor Mcnamara #:
On the discussion of static zigzag above, I argue that this is in fact suitable for live trading, the non repainting aspect means that you have a direct location for buy or sell signal. The zigzag won't paint too many legs if the period is high for calculation of the extremes. How it becomes useful for entry indication is that a bottom facing leg marks a support area (ideally) letting you know that the next leg HAS to be upwards as part of the structure. It's still not using math, but extremes based on a period are still extremes, which are useful pivot points. This non repainting structure is preferable for some. But the extremes themselves can be invalidated with a break of the market structure. Similarly in donchian channel.

that's true, no argument at all. It all depends on the strategy. I just use the dynamic version for trading and the static one for collecting statistics and setting levels. All levels based on the static one. The dynamic one is predictive in nature and makes entry faster by simply trying to predict the location of the current extreme after threshold is reached, or even the scale of the next extreme while the running extreme is not yet set in stone...

 
Conor Mcnamara #:
I just backtested this, and it's not bad actually, the lag is acceptable...it isn't that much lag which makes this reasonable

The lag is simply inversely related to the threshold value, which is calculated to the desired deviation value, of course the lag is larger if we try to use larger values ​​as extreme points. Mathematically it is simply not possible to do it differently... So there is no best zif zag algorithm , there is only a choice between the correct and the incorrect option, nothing more is possible! But who are interested to discuss...  Today I just built a new zigzag algorithm that determines basic statistical values ​​and also performs geometric calculations. We get all data only once passing through the raw data, using the (incremental computing) so-called stream processing solution. So we get all the valuable data without using any of additional arrays... Within one move through the source data and in addition to the zigzag movement values (which it would be prudent to store for future processing), the entire statistics are also available in the same pass. The algorithm goes through the history and presents statistics, after which it switches to live processing updating same statistics. In live we compare only the data of the current bar - with the data of previous bar -we use logical layers to manage the rest.... therefore it is extremely effective and optimal... just talking because it's an interesting topic and maybe it will help keep you motivated :)

123
New comment