A division by zero error appeared in one indicator - page 6

New comment
 
Aleksey Vyazmikin:

It should not logically be equal to zero at all - it is not clear why this is the case!

Your d1 gives out tiny numbers, I avoid such problems by converting price to int, i.e. for example int bid=int((tick_array[0].bid+_Point/10)/_Point); for sure, sometimes you get 0.00000999999 on 5 digits, if you do calculations in double
 
Aleksey Vyazmikin:

It shouldn't be zero by logic at all - I don't understand why it does that!

Run in debugger on Si-9.18. Time in rates is 2016 for some reason. Although the value of i is 2189. Accordingly, it starts the calculation at the beginning of the chart, where there is no liquidity. Initial time between start and stop is 1 hour. But for that hour, there is only one time value. It finds it with both the start and the stop variable. As a result, start = stop. Of course, if you subtract them, you get zero. I haven't figured out the rest yet.

 
ovak77:
You have d1 with tiny numbers, I avoid such problems converting price to int, i.e. for example int bid=int((tick_array[0].bid+_Point/10)/_Point); for sure, sometimes it returns 0 if calculations are performed in double

Let's not discuss d1 - if it's necessary, then it's necessary, everything is counted correctly there. The question is, why do we get the same value for start_time and stop_time, as well as start_index and stop_index?

 
Aleksey Vyazmikin:

Let's not discuss d1 - if it's necessary, then it's necessary, everything is counted correctly there. The question is why do we get the same value for start_time and stop_time as for start_index and stop_index ?

It's up to you, try dividing 0.0000099999 by 2, for example
 

After another hang-up, the terminal stops working.... How do I resurrect it without reinstalling?

Turned out to be hanging in memory - forcibly killed the process - it started.

 
Aleksey Vyazmikin:

How is it possible that the time becomes equal? Everything has been working correctly for half a year...

void CreateFigure(int i,const datetime &Time[],const double &Open[],const double &High[],const double &Low[],const double &Close[],MqlRates &rates[])
  {                                                              //i = 2189 
   datetime start_time=rates[i].time;                            //start_time=rates[i].time = D'2016.10.06 12:00:00'
   datetime stop_time=(start_time+PeriodSeconds(TimeFrames));    //stop_time = D'2016.10.06 13:00:00'
//---                                                            //Time[38572] = D'2016.10.05 19:23:00'
   int start_index,stop_index,limit;                             //Time[38571] = D'2016.10.06 12:35:00'
   datetime vertical_line_time;                                  //Time[38570] = D'2016.10.06 19:05:00'
//---
   start_index=ArrayBsearch(Time,start_time);                    //start_index = 38571
   if(Time[start_index]<start_time) start_index=(start_index>0?start_index-1:start_index);
   start_time=Time[start_index];                                 //start_time = D'2016.10.06 12:35:00'
   if(i>0)
     {
      stop_index=ArrayBsearch(Time,stop_time);                   //stop_index = 38571
      if(Time[stop_index]>stop_time) stop_index++;
      stop_time=Time[stop_index];                                //stop_time  = D'2016.10.06 12:35:00'
      limit=start_index-stop_index+1;
      vertical_line_time=Time[start_index-(limit>>1)];
You havelimit=start_index-stop_index+1 first, i.e.limit==1, and then where the division by 2 islimit=(int)(stop_time-start_time)/PeriodSeconds(_Period). One is not added. Zero is divided by the period.
 
Sergey Savinkin:

Run in debugger on Si-9.18. Time in rates is 2016 for some reason. Although the value of i is 2189. Accordingly, it starts calculation at the beginning of the chart where there is no liquidity. Initial time between start and stop is 1 hour. But for that hour, there is only one time value. It finds it with both the start and the stop variable. As a result, start = stop. Of course, if you subtract them, you get zero. I haven't figured out the rest yet.

Put BarsUsed=100 in the incoming parameters.

 
Aleksey Vyazmikin:

Put BarsUsed=100 in the incoming parameters.

Yes, this way no errors occur. But if you get into some illiquid instrument or illiquid time - evening session, for example, then you can easily get 1 low bar within an hour. Thus, the limit = 0 is guaranteed for you! And if the quote is 2 - then the limit/2 will still give 0 when rounded.

 
Sergey Savinkin:

Yes, that's not an error. But if you get into some illiquid instrument or illiquid time - for example, during the evening session, there might be 1 low bar in an hour. Thus, the limit = 0 is guaranteed for you! And if the quote is 2 - then the limit/2 will still be 0 when rounded.

Perhaps, I will think about it, thank you. But the global problem is something else.... The problem is that it's not stable.

 
ovak77:
It's up to you, try dividing 0.0000099999 by 2, for example

Printed d1 - for my purposes it's

2018.07.04 19:38:06.404 IndDrafter_Test (Si-9.18,M1)    d1=35.71428571428572
2018.07.04 19:38:06.404 IndDrafter_Test (Si-9.18,M1)    d1=32.78688524590164
2018.07.04 19:38:06.404 IndDrafter_Test (Si-9.18,M1)    d1=32.78688524590164
2018.07.04 19:38:06.404 IndDrafter_Test (Si-9.18,M1)    d1=32.78688524590164
2018.07.04 19:38:06.404 IndDrafter_Test (Si-9.18,M1)    d1=43.47826086956522

Anyway, that's not the point, thanks.

1234567891011
New comment