A little surprised :) Thought I'd share and ask a NOT rhetorical question. - page 7
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
The point is not in the tester, again! Not in the tester, but in real conditions where history is downloaded and connection failures occur.
If a reset and recalculation of the indicator happens in real life, there is nothing wrong with it.
Another question has arisen. Don't most people have nothing to do here? They are rewriting the terminal standard functionality for mql5. Perhaps, somebody will write a whole terminal on mql5 very soon.
If, under real conditions, a reset and recalculation of the indicator occurs, there is nothing wrong with this.
Another question has arisen. Don't most people have nothing to do here? They are rewriting the terminal standard functionality for mql5. Perhaps, someone will write a whole terminal on mql5 very soon.
Of course, it is not so bad. When you have 100 ZUP in one terminal (just for example), it's OK...
The same question came up. Everyone likes to talk only from their point of view, why?
There is more than one indicator used here:
The influence of standard IndicatorCount function is just killer for it (I checked it personally). And when implemented as classes, communication discontinuities are even purple
P.S. For one MA it is of course not a big deal
Of course it's no big deal. When you have 100 ZUPs in one terminal (just to give you an example), it's no big deal...
The same question has arisen. Everyone likes to argue only from their own bell tower, why?
Somebody always wants more than they can handle. But why so many?
The problem of resetting the indicator can be solved with five lines of code. Remember the time of the first bar, if it has changed, you need a full recalculation. Store the number of the last bar, in case of a reset continue recalculation from this bar and that's it.
I'm not afraid to say from my own bell tower, without confirming anything with arguments that my bell tower is correct, full stop.
Someone always wants more than they can handle. But why so much?
You can get around the problem of resetting the indicator with five lines of code. Remember the time of the first bar, if it has changed, a full recalculation is needed. Store the number of the last bar, in case of a reset continue recalculation from this bar and that's it.
I'm not afraid to say from my bell tower, without confirming anything with arguments that my bell tower is correct and that's it.
Don't be so self-righteous. Learn to not only listen, but to hear others.
The story can change in the middle and your approach will go to tatters. Ask Renat about this.
The error in IndicatorCounted() in MT4, which was fixed with my tip only now, sent even correctly written indicators to the scrap (especially ZigZag on small TFs).
Not to mention your approach to this case....
Not even going to argue with you because you are completely wrong in this situation.
Don't be so self-confident in yourself. Learn not only to listen but also to hear others.
The story can change in the middle and your approach will go into tatters. Ask Renat about this.
The error in IndicatorCounted() in MT4, which was corrected only now with my tip, sent even correctly written indicators to garbage (especially ZigZag on small TF).
I'm not even going to argue with you, because you are completely wrong in this situation.
Add a couple more checks at the time of reset, whether the number of bars has increased, but the bar time has not changed or more than one bar has been added.
As for being overconfident, it's the other way around, you are the overconfident one, you are the third one who thinks he is cooler than MQ.
Add a couple more checks at the time of reset, whether the number of bars has increased but the bar time has not changed or more than one bar has been added.
About the self-confidence, it's the other way around, you're all the overconfident ones here, you're the third one who thinks he's cooler than MQ.
What kind of checks? Situation. A new tick appears on the old bar. Nothing has changed - neither the total number of bars, nor the last bar open time, but at the same time
the last 30 bars have been rewritten (their open/close prices, max, min, have changed, though insignificantly).
What will you do with your algorithm? Nothing! It simply will not work in this situation. And the indicator will be completely incorrect!
What was in MT4 before the last builds - in 70% of cases it wouldn't react to this situation.
But after analysis of the problem they fixed it. Stingo wrote about it: https://www.mql5.com/ru/forum/132422
I do not think I am cooler than others. On the contrary, I actively help to fix all the bugs in MT4 and MT5 - ask any MetaQuotes representative.
And the fact that some mechanisms are not implemented the way you want - you can't please everyone....
It is an interesting question as to what is correct, what was before or what was after the history correction. If you don't go back to the corrected bars, the indicator will continue to work as if the history was not corrected. Hrenfx has exactly this attitude, he considers the old history correct, you have the opposite.
There is also an opinion that you should only use regular prev_calculated, with no variations. If the indicator is heavy, limit the number of bars counted at startup. The rest is a tambourine dance, the result is doubtful.
It is an interesting question as to what is correct, what was before or what was after the history correction. If you don't go back to the corrected bars, the indicator will continue to work as if the history was not corrected. Hrenfx has exactly this attitude, he considers the old history correct, you have the opposite.
There's also the opinion that you should only use the regular prev_calculated, unvariably. If the indicator is heavy, limit the number of bars counted at startup. The rest is dancing with tambourine, the result is doubtful.
Everyone decides for themselves what is considered correct and what is not. For ZigZag the above situation is totally killer. For MA, there will be a 0.0001 deviation in its value...
Opinion can often be imposed (I'm not saying it's wrong).
In general, I suggest to end the discussion here. Theoretical reasoning will not get you anywhere.
In the tester, the custom optimization of the indicator calculations will work perfectly, but in the client terminal can cause unpleasant shifts of the history and incorrect calculations.
By the way, mt5 uses very effective and instantaneous control of historical base integrity in rltime, which increases frequency of resetting prev_counted to zero. If you do not consider this counter correctly, and deal with your own optimizations, you can catch a lot of problems in real work. Updates of the minute history are instantly delivered to the terminals by the server itself.
In the tester, the custom optimization of indicator calculations will work perfectly, but in the client terminal can cause unpleasant shifts of the history and incorrect calculations.
That's what I mean too.
Maybe you'll think about how to reset prev_counted not to zero, but to the first unchanged value?