Hi,
i know that terminal could set prev_caclulated=0 when "If the price data have been changed since the last call of the OnCalculate() function (a deeper history has been loaded or gaps in the history have been filled), the value of the prev_calculated input parameter is set to zero by the terminal itself", but what exactly happen to indicator buffer?
Parameter prev_calculated is the result of the execution of OnCalculate() at the previous call; it allows organizing a saving algorithm for calculating indicator values. For example, if the current value rates_total = 1000, prev_calculated = 999, then perhaps it's enough to make calculations only for one value of each indicator buffer.
If the information about the size of the input array price would have been unavailable, then it would lead to the necessity to make calculations for 1000 values of each indicator buffer. At the first call of OnCalculate() value prev_calculated = 0. If the price[] array has changed somehow, then in this case prev_calculated is also equal to 0."
Therefore, the indicator buffer is updated as it is recalculated on new data.
Is it correct that rates_total is reset to "max bar chart" terminal option?
Assuming that you reset "Max bars in chart" and restart MT5, yes, rates_total is all of the bars in the chart.
And what happen to buffer data when this happens? Is buffer "truncated" at left (older history) ?
It depends how your indicator is coded. If your code has a limited buffer lookback loop, the entire buffer is recalculated and updated. If your code has a rates_total buffer loop with a nested limited lookback loop within it, then most of the buffer history is not updated─only the lookback period is updated.
Anytime that prev_calculated doesn't equal rates_total, prev_calculated is 0. This includes delayed bars appearing in your chart from the data server. The bars that were missing are now there.
- www.mql5.com
If the price[] array has changed somehow, then in this case prev_calculated is also equal to 0."
Assuming that you reset "Max bars in chart" and restart MT5, yes, rates_total is all of the bars in the chart.
Yes i know it, i'm asking if it is correct that after it reaches e.g. 1000155, terminal resets it to 1000000 again.
It depends how your indicator is coded. If your code has a limited buffer lookback loop, the entire buffer is recalculated and updated. If your code has a rates_total loop with a nested lookback loop within it, then most of the buffer history is not updated─only the lookback period is updated.
No. I would know what do the terminal, not what do my code. What happen to e.g. 1000155 calculated indexes buffer? They are truncated to left removing 155 calculated bars?
Anytime that prev_calculated doesn't equal rates_total, prev_calculated is 0. This includes delayed bars appearing in your chart from the data server. The bars that were missing are now there.
Which bars coul be missing from previous call? Old bars in the history? That's not clear.
Somehow, how? That's the point.
Yes i know it, i'm asking if it is correct that after it reaches e.g. 1000155, terminal resets it to 1000000 again.
No. I would know what do the terminal, not what do my code. What happen to e.g. 1000155 calculated indexes buffer? They are truncated to left removing 155 calculated bars?
Which bars coul be missing from previous call? Old bars in the history? That's not clear.
This is perfectly by design and documented. Bar number in a chart can be limited to specific value, if assigned in the terminal settings. When the limit is reached terminal will add new bars as time passes, so the number can become larger than the limit (actual value may vary - not necessarily 1000155 if the limit is 1000000). But after that, terminal can free up excessive bars at arbitrary moment. Of course, most outdated bars are dropped, and most recent are preserved.
You seem to be suggesting that the OP had set "Max bars in chart" at 1000000, accumulated 1000155 bars, and then wondered where the 155 bars went. If that's the case, the joke is clearly on me.
In any event, I always set "Max bars in chart" at Unlimited without issue─to do so, hardware and software run have to support that.
This is perfectly by design and documented. Bar number in a chart can be limited to specific value, if assigned in the terminal settings. When the limit is reached terminal will add new bars as time passes, so the number can become larger than the limit (actual value may vary - not necessarily 1000155 if the limit is 1000000). But after that, terminal can free up excessive bars at arbitrary moment. Of course, most outdated bars are dropped, and most recent are preserved.
When terminal free up excessive bars (even if i think is not my case) it resets prev calculated to 0 ?
You seem to be suggesting that the OP had set "Max bars in chart" at 1000000, accumulated 1000155 bars, and then wondered where the 155 bars went. If that's the case, the joke is clearly on me.
In any event, I always set "Max bars in chart" at Unlimited without issue─to do so, hardware and software run have to support that.
No, i just would know why terminal resets prev calculated of my indi to 0 at some point, causing recalculate overall history of my indicator. I would avoid continue recalculations of overall bars. So i'm looking the reason of it, and trying to find a way to avoid it, or to avoid it happens too many times.
Normally, prev_calculated is reset to 0 if terminal "thinks" that some past data (deeper than the latest bar) has been changed, if it's not you who returned 0 from previous call of your indicator. You can check, if the reset is dispatched to all indicators or only to yours.
For the 1-st case there can be many reasons, some are more or less intuitive for the users and others are just speculations (for example, the terminal detects changes in hashes of historical quotes/ticks on the server - but don't ask me why this can happen, connection is dropped and restored (probably after a big timeout, or with another access point which can provide slightly different history, etc.)). We are living in the imperfect world.
When terminal free up excessive bars (even if i think is not my case) it resets prev calculated to 0 ?
I don't know, and I'd say this can be implementation specific (in other words, MQ can re-decide to handle it differently from time to time). Otherwise this could be documented.
On the one hand, the recalculation is not needed (logically), when old fraction of history is wiped out, but on the other, an MQL5 program may have internal data structures allocated for bars, and simple shrinking of the buffer will screw up the sync between the bars and internal structures, so the most simple way to send a "signal" (to the indicator that it should rebuild its internal structures) is to recalculate completely.
I don't know, and I'd say this can be implementation specific (in other words, MQ can re-decide to handle it differently from time to time). Otherwise this could be documented.
On the one hand, the recalculation is not needed (logically), when old fraction of history is wiped out, but on the other, an MQL5 program may have internal data structures allocated for bars, and simple shrinking of the buffer will screw up the sync between the bars and internal structures, so the most simple way to send a "signal" (to the indicator that it should rebuild its internal structures) is to recalculate completely.
Send a "signal" that we don't know the reason of, is not "implementation" specific, is absurde logic. After a lot of posts, we are again on the same point. I would know the reason prev_calculated is reset to 0, so that in my code i can decide what to do.
Im my indicator, i use ticks (using CopyTicks) and not refer to bars, so i would know if buffers are modified when prev_calculated is reset to 0, and how.
Im my indicator, i use ticks (using CopyTicks) and not refer to bars, so i would know if buffers are modified when prev_calculated is reset to 0, and how.
There you have it. It's the proverbial, "your code."
Ticks are more likely to be skipped in the first place and hence, they are more likely to suddenly backfill at a later time. Of course, any backfilled tick that affects bar open price, close price, etc. creates a change.
The OnTick() event handler in the form of an EA might be more appropriate for whatever your code is.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi,
i know that terminal could set prev_caclulated=0 when "If the price data have been changed since the last call of the OnCalculate() function (a deeper history has been loaded or gaps in the history have been filled), the value of the prev_calculated input parameter is set to zero by the terminal itself", but what exactly happen to indicator buffer?
Looking a this behaviour:
Is it correct that rates_total is reset to "max bar chart" terminal option?
And what happen to buffer data when this happens? Is buffer "truncated" at left (older history) ?
What exactly "gaps in the history have been filled" mean?