Randomically prev_calculated set to 0 by terminal

 

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: 

MyIndi (USTEC,M1)       prev: 0 rates_tot: 1000000
MyIndi (USTEC,M1)       prev: 1000000 rates_tot: 1000001
MyIndi (USTEC,M1)       prev: 1000001 rates_tot: 1000002
MyIndi (USTEC,M1)       prev: 1000002 rates_tot: 1000003
MyIndi (USTEC,M1)       prev: 1000003 rates_tot: 1000004
MyIndi (USTEC,M1)       prev: 1000004 rates_tot: 1000005
........
........
........
MyIndi (USTEC,M1)       prev: 0 rates_tot: 1000000

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?

 
antony23:

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?

"[T]he rates_total variable contains the value of the total number of elements of the price[] array, passed as an input parameter for calculating indicator values.

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.

antony23:
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.

antony23:
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.

Ryan L Johnson #:
What exactly "gaps in the history have been filled" mean?

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.

Documentation on MQL5: Custom Indicators
Documentation on MQL5: Custom Indicators
  • www.mql5.com
This is the group functions used in the creation of custom indicators. These functions can't be used when writing Expert Advisors and Scripts...
 
Ryan L Johnson #:
If the price[] array has changed somehow, then in this case prev_calculated is also equal to 0."
Somehow, how? That's the point.
Ryan L Johnson #:
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.

Ryan L Johnson #:
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?

Ryan L Johnson #:

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.

 
antony23 #:
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.
 
Stanislav Korotky #:
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.

 
Stanislav Korotky #:
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 ?

 
Ryan L Johnson #:

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.
 
antony23 #:
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.

 
antony23 #:

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.

 
Stanislav Korotky #:

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.

 
antony23 #:

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.