Errors, bugs, questions - page 3149

New comment
 
Vladimir Karputov #:

Step 1: Create a template using 'MQL5 Wizard':


Step 2: Spell 'limit' correctly and USE the close array - NOT the iClose call!!!


Result:

and there are no errors.

Who said this is the only correct calculation of limit and indicator?

We are discussing another calculation of limit and the indicator itself - from left to right - from the beginning of history to the current time. It is simpler and more evident.

In such a calculated limit (int limit = rates_total - prev_calculated; if(limit>1) limit=rates_total-1;) all data about

  1. whether it is a current tick,
  2. whether it is a new bar opening,
  3. whether it is a change of history data.

If the current tick (limit==0), then for(int i=limit; i>=0; i--) { // . } will calculate the indicator on every new tick, and only the zero bar will be recalculated.

If we open a new bar (limit==1), then for(int i=limit; i>=0; i--) { // ... } will perform the calculation of the first and the zero bar - the previous and the newly opened bar.

If this history change (limit>1), then for(int i=limit; i>=0; i--) { // ... } will perform full recalculation of the indicator for all available history (the history has been changed somewhere)

 
TheXpert #:
What difference does it make? Can it get less than zero?

Yes, I have (added to previous post)

 
Artyom was the only one who understood the problem.
But apparently this problem is forever.
And now there are only ifs.
 
Roman #:
Only Artyom understood the problem.
But apparently this problem is forever.
And now there are only ifs.

No, I didn't get it. Clarify what I understood...

 
Vladimir Karputov #:
   int limit=prev_calculated-1;
   if(prev_calculated==0)
      limit=0;
   for(int i=limit; i<rates_total; i++)
     {
      CloseBuffer[i]=close[i];
     }

ternary operator looks more laconic (IMHO)

int limit = prev_calculated==0 ? 0: prev_calculated-1;

Moreover, as I said before, what if something goes wrong and prev_calculated turns out to be higher than rates_total.
I encountered such a situation, when the max bars in the window are != unlimited, but for example, 50000. In that case, the size of the bar array would increase by 1 with every new bar, but at some moment it would become 50000 again. I do not follow the logic. I caught it a couple of years ago. Need to check it now. I'll set up an unlock on my VPS.

 
Artyom Trishkin #:

No, I didn't get it. Clarify what I understood...

What for now doesn't work as before

limit==0
for ticks i>=0
for bars i>0

You've written everything correctly above,
only for new bar misprintedfor(int i=limit; i>=0; i--)
the operator = is not needed here, but it's probably in the past,
unless they return the previous behaviour.

 
Roman #:

What for now does not work as before

limit==0
for ticks i>=0
for bars i>0

You've written everything correctly above,
only for new bar it's misprintedfor(int i=limit; i>=0; i--)
here operator = is not needed, but it must be in the past already,
if not return the previous behaviour.

Again I don't understand anything. What's wrong with it? Everything seems to be as it was before.

 
Artyom Trishkin #:

I don't get it again. What's wrong with it? Everything seems to be as it was before.

With this design.

int limit = rates_total-prev_calculated;

for(int i=limit; i>=0; i--)


 indicator buffer is out of bounds.

Please show me an example forticks with cycle i>=0
maybe I've forgotten something and am doing it wrong.

 
Roman #:

With this design
, the indicator buffer goes out of bounds.

has always gone out.
 
Roman #:

With this design.


 indicator buffer is out of bounds.

Please show me an example forticks with cycle i>=0
maybe I've forgotten what I'm doing wrong.

I already wrote that with this construction you are accessing the buffer index with rates_total (when prev_calculated == 0 ).
And this is an overflow because rates_total is the size of the buffer whose last element rates_total-1

1...314231433144314531463147314831493150315131523153315431553156...3189
New comment
Reason: