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

 
Vladimir Karputov:

You need the minimum code reproducible by the problem. Not a piece of code.

The problem is unstable - it may not exist for hours and then appear. I have shown the piece where division by zero occurs and the piece that forms the divider. It is not yet clear what else might be causing it.

 
Aleksey Vyazmikin:

The problem is unstable - it may not exist for hours and then appear. I have shown the piece where division by zero occurs and the piece that forms the divider. It is not yet clear what else might be causing it.

You, on the other hand, have the LINE NUMBER and the COURSE POSITION of the division by zero. But unfortunately we are not telepaths.

Is it difficult for you to highlight the line and the cursor position?
 
Aleksey Vyazmikin:

Which line is the error in? Highlight it in the code.

 
Aleksey Vyazmikin:

The problem is unstable - it may not exist for hours and then appear. I've shown the piece where division by zero occurs and the piece that forms the divider. It is not yet clear what else could be the cause.

Maybe it's a matter of type conversion (int) - somewhere a fractional number is formed when dividing and it int becomes zero. Of course, the divisor is converted to integer, but type conversion was already complained about with the new release.

 
Vladimir Karputov:

You, on the other hand, have the LINE NUMBER and the CURSOR POSITION of the division by zero. But, unfortunately, we are not telepaths.

Is it difficult for you to select the line and the cursor position?
Alexey Kozitsyn:

What line is the error in? Highlight it in the code.

Here's what I wrote.

Here it becomes zero.TimeFrames==PERIOD_H1

double d1=(delta_price_high-center_line_point)/(limit/2);

The debugger shows these dates

2018.07.04 11:33:11.674 2018.07.01 00:00:00   start_time - 2018.06.28 15:00 stop_time - 2018.06.28 16:00
2018.07.04 11:33:11.688 2018.07.01 00:00:00   start_time - 2018.06.28 16:00 stop_time - 2018.06.28 17:00
2018.07.04 11:33:11.701 2018.07.01 00:00:00   start_time - 2018.06.28 17:00 stop_time - 2018.06.28 18:00
2018.07.04 11:33:11.714 2018.07.01 00:00:00   start_time - 2018.06.28 18:00 stop_time - 2018.06.28 18:44
2018.07.04 11:33:11.727 2018.07.01 00:00:00   start_time - 2018.06.28 19:05 stop_time - 2018.06.28 20:00
2018.07.04 11:33:11.740 2018.07.01 00:00:00   start_time - 2018.06.28 20:00 stop_time - 2018.06.28 21:00
2018.07.04 11:33:11.754 2018.07.01 00:00:00   start_time - 2018.06.28 21:00 stop_time - 2018.06.28 22:00
2018.07.04 11:33:11.767 2018.07.01 00:00:00   start_time - 2018.06.28 22:00 stop_time - 2018.06.28 23:00
2018.07.04 11:33:11.783 2018.07.01 00:00:00   start_time - 2018.06.28 23:00 stop_time - 2018.06.28 23:49
2018.07.04 11:33:11.796 2018.07.01 00:00:00   start_time - 2018.06.29 10:00 stop_time - 2018.06.29 11:00
2018.07.04 11:33:11.810 2018.07.01 00:00:00   start_time - 2018.06.29 11:00 stop_time - 2018.06.29 12:00
2018.07.04 11:33:11.823 2018.07.01 00:00:00   start_time - 2018.06.29 12:00 stop_time - 2018.06.29 13:00
2018.07.04 11:33:11.836 2018.07.01 00:00:00   start_time - 2018.06.29 13:00 stop_time - 2018.06.29 13:59
2018.07.04 11:33:11.850 2018.07.01 00:00:00   start_time - 2018.06.29 14:05 stop_time - 2018.06.29 15:00
2018.07.04 11:33:11.863 2018.07.01 00:00:00   start_time - 2018.06.29 15:00 stop_time - 2018.06.29 16:00
2018.07.04 11:33:11.876 2018.07.01 00:00:00   start_time - 2018.06.29 16:00 stop_time - 2018.06.29 17:00
2018.07.04 11:33:11.893 2018.07.01 00:00:00   start_time - 2018.06.29 17:00 stop_time - 2018.06.29 18:00
2018.07.04 11:33:11.906 2018.07.01 00:00:00   start_time - 2018.06.29 18:00 stop_time - 2018.06.29 19:00
2018.07.04 11:33:11.920 2018.07.01 00:00:00   start_time - 2018.06.29 19:00 stop_time - 2018.06.29 20:00
2018.07.04 11:33:11.933 2018.07.01 00:00:00   start_time - 2018.06.29 20:00 stop_time - 2018.06.29 21:00
2018.07.04 11:33:11.946 2018.07.01 00:00:00   start_time - 2018.06.29 21:00 stop_time - 2018.06.29 22:00
2018.07.04 11:33:11.959 2018.07.01 00:00:00   start_time - 2018.06.29 22:00 stop_time - 2018.06.29 23:00
2018.07.04 11:33:11.973 2018.07.01 00:00:00   start_time - 2018.06.29 23:00 stop_time - 2018.06.30 00:00
2018.07.04 11:33:12.351 2018.07.02 10:00:00   start_time - 2018.06.29 23:00 stop_time - 2018.06.29 23:49
2018.07.04 11:33:12.382 2018.07.02 10:00:00   start_time - 2018.07.02 10:00 stop_time - 2018.07.02 11:00

Condition for the print

         if (limit>0){limit=2;Print("start_time - ",TimeToString(start_time,TIME_DATE|TIME_MINUTES)," stop_time - ",TimeToString(stop_time,TIME_DATE|TIME_MINUTES));}
 
It turns out that the dates are in order...
 
Sergey Savinkin:

Maybe it's a matter of type conversion (int) - somewhere during division a fractional number is formed and it is converted to zero by the int. Of course, the divisor is converted to integer, but type conversion was already complained about with the new release.

Perhaps we need to think about it.

 
Aleksey Vyazmikin:

Obviously, you need to check the limit by 0. The condition for the print is incorrect, I think. You should print when limit=0.

 
Alexey Kozitsyn:

Obviously, you need to check the limit by 0. The condition for the print is incorrect, I think. It should print when limit=0.

Thanks - I'm dumbfounded when I'm awake.

 
In general, profiling on historical data reveals no errors.