What the Lowest and Highest functions return - page 3

New comment
 
Candid, I will try to describe the instability of the operation .

One option. There are others.
We have the first ray. For simplicity - coming from the zero bar. The zero bar has a maximum and a minimum. The price moves inside the bar without changing its extrema. Since the extrema are not changing, the first ray should stand still and not move. But it doesn't. The first ray jerks. Changes its position. This is merely a description of the external manifestation of instability. If the algorithm works stably and the market parameters (maximum and minimum of the last bar), on which the zigzag operation depends, do not change, the first ray should not falter. I have struggled with this problem on my own. But the noticed peculiarities of the search functions have forced me to go to the forum.
========================
When we move the window (shift,shift+ExtDepth) while calculating the indicator, the appearance of a new extremum may be related either to a new price or to the old extremum having left the window. - It would be better to specify it explicitly. To make it clear. In the language description. So as not to explore the hidden possibilities of the language.

For this purpose, the line if(highpos!=shift) val=0.0; . How this is done in the standard code, I don't understand. Judging by the fact that dangling extrema disappear in my variant, it is either not done correctly or not done at all. - My solution to this issue is different: if (High[shift]=val) ZigZagBuffer[shift]=val; and if (Low[shift]=val) ZigZagBuffer[shift]=val;
But in sense it is the same thing. But it does not solve all the problems. It is the way we fight the consequence and not the cause. Tried to fight the consequence in the same way. But on the first ray it does not work. The thing is that the zigzag algorithm, shall we say, does not dissect. Let me explain this. Calculation is performed over the entire history. And if we correct some part of it, the processing remains incomplete near the zero bar, so to say. I cannot find the right words. So this incompleteness near the zero bar brings out the problem of identifying extrema correctly.

I tried to adjust window parameters (shift,shift+ExtDepth) not so long ago. I was experimenting with the window the other day as well. But so far without result.
 
The point is that the zig-zag algorithm, shall we say, does not dissect. Let me explain this. The calculation is performed over the entire history. And if we correct some part of it, the processing still remains incomplete near the zero bar, so to say. I cannot find the right words. So this incompleteness near the zero bar brings out the problem of identifying extrema correctly. <br/ translate="no">.


This problem is known and is fixed theoretically (I have the algorithm in my head long ago). Anyway, if no other solution appears, I will optimize the Zigzag algorithm. It is done as follows:
1) the first run is made over the entire history as in the current algorithm
2) on every tick from zero bar deep into the history, two extrema of the Zigzag are searched for, the last extremum is forcibly killed.
3) from the last one (now the last one) again follows the standard procedure of Zigzag calculation.
4) if the current end (the tail of the ZigZag) can theoretically be an extremum (we have the Highest from the last Low or vice versa), it also becomes an extremum.
5) with a new tick all over again from point 2)
 
nen:
But it didn't happen. The first beam twitches. It changes its position.

I haven't seen this yet. Does it leave one end of the beam fixed? And which one. If it is on the zero bar, maybe one should take a closer look at conditions where variables of the double type are compared?

When we move the window while calculating the indicator (shift,shift+ExtDepth), the appearance of a new extremum may be related either to the new price or to the old extremum having left the window. - It would be better to specify it unambiguously. To make it clear. In the language description.

This seems to me to refer to the algorithm rather than the language. So, a reminder that the functions we are discussing are actually looking for the maximum (minimum) price value over the interval, rather than an extremum, would be appropriate in a book or in some commentaries.
To do this in my insert the line if(highpos!=shift) val=0.0; . How this is done in the standard code, I don't understand. Judging by the fact that dangling extrema disappear in my variant, it is either not done correctly or not done at all. - I have this point solved differently: if (High[shift]=val) ZigZagBuffer[shift]=val; and if (Low[shift]=val) ZigZagBuffer[shift]=val;
I like my version better :). It works with integers. In such a comparison of doubles (like Low[shift]==val) just may appear beats.
 
Rosh, I have the same option. In my head. There are some vague points stopping me from realising it. Let's put it this way. Point 4) is somewhat out of the algorithm. It is already another algorithm. And when the section processed in item 4) will be available to history, its processing with the algorithm starting from item 1) may lead to drawing other extrema. That is, the real-time and history will be different. This, in my opinion, is not acceptable.
 
Rosh I have the same option. In my head. There are some vague points stopping me from realising it. Let's put it this way. Point 4) is somewhat out of the algorithm. This is a different algorithm. And when the section processed in item 4) will be available to history, its processing with the algorithm starting from item 1) may lead to drawing other extrema. That is, the real-time and history will be different. This, in my opinion, is not acceptable.


point 4) on the next tick is processed with a file through point 2)
 
Дело в том, что алгоритм зигзага, скажем так, не расчленяется. Поясню это. Просчет проводится по всей истории. И если мы в какой-то части исправим ошибки, то в районе нулевого бара процесс обработки остается, скажем так, незавершенным. Затрудняюсь подобрать правильные слова. Так вот эта незавершенность в районе нулевого бара и вытаскивает на свет проблему правильного поиска экстремумов.


This problem is known, and theoretically fixed (there has been an algorithm in mind for a long time).
Is there a verbal description of what the zigzag should do? Something like a technical specification.
 
I haven't seen this yet. Does it leave one end of the beam attached? And which one. If it is on zero bar, then maybe one should take a closer look at conditions where variables of double type are compared?
The matter is that I am testing the indicator that uses the zigzag in very strict conditions. On minutes and with 2-1-1 parameters. What is the purpose of such testing? This kind of testing reveals all of the hidden flaws quite quickly. Plus there is a desire for the indicator to work on all timeframes without exception. The market is a fractal thing. There are many people who trade on minutes. Why should we deprive them of the opportunity to work with the familiar tool on small timeframes?

I like my version better.) It works with integers. When performing such a comparison of doubles (of type Low[shift]==val) it may cause beats.
So far I haven't encountered any difficulties working with double. These numbers are stored in memory unchanged. But my comparison takes values from a single memory cell. If there will be a problem in this place, it is a matter of hardware (i.e. computer) issue. Something has to be done with the hardware.

It seems to me that this refers not to the language, but to the algorithm. Thus, a reminder that the functions we are discussing are actually looking for the maximum (minimum) price value over the interval, rather than an extremum, would be appropriate for a book or some comments.

I just called it an extremum. It is actually the maximum and minimum of the chosen interval. It's a long pronunciation. But the meaning is the same.
 
Is there a verbal description of what the zigzag should do? Something like a terms of reference?
There was for a long time on CodeBase.mql4.com. But that description is very difficult to understand. And contradictory. Over the summer, I think Slava fine-tuned the code of the zigzag. Only part of the previous description was left on the site after that.
 
nen:
Working with double has not caused any difficulties so far. These numbers are stored in memory unchanged. And my comparison takes values from a single memory location. If a problem occurs here, it is a question of the hardware - the computer. Something has to be done with the hardware.
Well, I'm guided by the code in the branch. And it calculates val every time. It's just safer not to use == when comparing dou
 
Well, I'm based on the code in the branch. And it calculates val every time. That's right, it does. The number of a cell is found. From this cell (time series), the value of maximum or minimum bar is taken. It is considered that the maximum has been found on this bar. This value is then placed in the indicator buffer with the found number. The maximum of the indicator should correspond to the maximum on the bar. In my code, maximum is also taken from the array (timeseries) with the same found number and compared to the value of val. It is checked to see if we are doing the right thing: we put into the buffer with this number the value of val. It should also be equal to the maximum of the bar. Comparison of numbers taken from the same place is quite correct.
1234567
New comment