Randomically prev_calculated set to 0 by terminal - page 2
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
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.
Just as a by side example, can you imagine how many reasons could be that a connection is dropped for a while? There are too much, and any of them can be handled in different manner. Memory reallocations is another aspect, which could force recalculation. And so on. In every software there is a lot of internal implemention "tricks" which are not documented and cannot be documented. You need to use public API, not ask how it's implemented inside. For open source software you can find the answer yourself, if you want, but MT5 is a private proprietary thing.
In other words - you don't need to know why prev_calculated is reset to 0, you need only to handle such situations properly. It's very well known 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.
I got an answer to this question. When terminal reset prev_calculated to 0 and rates_total to "max bars chart", it removes (free up) recent calculated indexes buffer, and not the oldest ones.
E.g. if rates_total is 50015 and terminal reset buffers to 50000, it removes the recent 15 calculated indexes (from 0 to 14 in timeseries), keep the oldest indexes untuched.
That's a really weird logic, why don't remove oldest ones and shift newest indexes? This would avoid recalculate indicators (if we don't care about oldest data). While removing the newest data, it forces us to recalculate the entire buffer!
I got an answer to this question. When terminal reset prev_calculated to 0 and rates_total to "max bars chart", it removes (free up) recent calculated indexes buffer, and not the oldest ones.
E.g. if rates_total is 50015 and terminal reset buffers to 50000, it removes the recent 15 calculated indexes (from 0 to 14 in timeseries), keep the oldest indexes untuched.
That's a really weird logic, why don't remove oldest ones and shift newest indexes? This would avoid recalculate indicators (if we don't care about oldest data). While removing the newest data, it forces us to recalculate the entire buffer!
I don't think you're right. Terminal removes most outdated quotes while shrinking excessive data. Probably, your misunderstanding comes from the fact that quotes are indexed in reversed order (called "as series") - 0-th index is the current bar.
Whatever data are removed, you can't count on that. The whole buffers should be recalculated when prev_calculated = 0.
Of course so (and I did not mention anything to the contrary), but my reply was an objection to the statement, that most recent bars are removed, which is not true.
My indicator is a renko bar indicator, built on ticks dara and not on timeseries data. I don't need to recalculate all buffers when prev_calculated is 0, it is not mandatory in this case.
I tried setting buffers as series, but also as not series, anyway i can confirm that when terminal shrink buffers it cleans the most right indexes, meaning the most right ones in memory, indipendently of indexing order.
Here a sample code to check. Put it on M1 chart. I set my max bars to 1000000.
At some point, right click on chart and click "Refresh", so terminal reset prev_calculated to 0 and rates_total to 1000000. Here the log:
As you can see, when i clicked Refresh, the 0 element was 9, so it removed newest indexes elements.
It is simple to try without as series, comment "ArraySetAsSeries(line_data,true);". Here the log:
Even so, the newest indexes elements was removed.
So it seems to me clear that terminal free up the most right element in memory, indipendently from indexing order.
My indicator is a renko bar indicator, built on ticks dara and not on timeseries data. I don't need to recalculate all buffers when prev_calculated is 0, it is not mandatory in this case.
I tried setting buffers as series, but also as not series, anyway i can confirm that when terminal shrink buffers it cleans the most right indexes, meaning the most right ones in memory, indipendently of indexing order.
Here a sample code to check. Put it on M1 chart. I set my max bars to 1000000.
At some point, right click on chart and click "Refresh", so terminal reset prev_calculated to 0 and rates_total to 1000000. Here the log:
As you can see, when i clicked Refresh, the 0 element was 9, so it removed newest indexes elements.
It is simple to try without as series, comment "ArraySetAsSeries(line_data,true);". Here the log:
Even so, the newest indexes elements was removed.
So it seems to me clear that terminal free up the most right element in memory, indipendently from indexing order.
This is unreliable.
You ALWAYS have to recalculate when prev_calculated = 0 because you CAN'T know what the Terminal will do with your buffers. It's not documented, not under MQL developer control, so the only way to deal with it reliably is to recalculate all.
This is unreliable.
You ALWAYS have to recalculate when prev_calculated = 0 because you CAN'T know what the Terminal will do with your buffers. It's not documented, not under MQL developer control, so the only way to deal with it reliably is to recalculate all.
Yes, I understood it unfortunately. This improvement could be an important optimization... why don't they do it ?!
Thanks anyway.