一个指标出现了除以零的错误 - 页 2

 
Vladimir Karputov:

你需要的是问题可重现的最小代码。不是一段代码。

这个问题是不稳定的--它可能在几个小时内不存在,然后又出现。我已经展示了发生除以0 的部分和构成除数的部分。目前还不清楚还有什么原因可能导致这种情况。

 
Aleksey Vyazmikin:

这个问题是不稳定的--它可能在几个小时内不存在,然后又出现。我已经展示了发生除以0 的部分和形成除数的部分。目前还不清楚还有什么原因可能导致这种情况。

另一方面,你有行数和除以0的COURSE位置。但不幸的是,我们不是心灵感应者。

对你来说,突出显示这一行和光标位置是否有困难?
 
Aleksey Vyazmikin:

错误在哪一行?在代码中突出它。

 
Aleksey Vyazmikin:

这个问题是不稳定的--它可能在几个小时内不存在,然后又出现。我已经展示了发生除以0 的部分和构成除数的部分。目前还不清楚还有什么可能是这个原因。

也许是类型转换的问题(int)--在除法过程中某个地方形成了一个小数,它的int变成了0。当然,除数被转换为整数,但类型转换在新版本中已经被抱怨过了。

 
Vladimir Karputov:

另一方面,你有LINE NUMBER和除以0的CURSOR POSITION。但是,不幸的是,我们不是心灵感应者。

对你来说,选择行和光标位置是否有困难?
阿列克谢-科齐岑

错误在哪一行?在代码中突出它。

这是我写的。

这里变成零。TimeFrames==PERIOD_H1

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

调试器显示这些日期

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

印刷品的条件

         if (limit>0){limit=2;Print("start_time - ",TimeToString(start_time,TIME_DATE|TIME_MINUTES)," stop_time - ",TimeToString(stop_time,TIME_DATE|TIME_MINUTES));}
 
事实证明,这些日期是有顺序的...
 
Sergey Savinkin:

也许是类型转换的问题(int)--在除法过程中的某个地方形成了一个小数,它被int转换为零。当然,除数被转换为整数,但类型转换在新版本中已经被抱怨过了。

也许我们需要考虑一下。

 
Aleksey Vyazmikin:

很明显,你需要检查0的限制,我认为打印的条件不正确。你应该在limit=0时打印。

 
Alexey Kozitsyn:

很明显,你需要用0来检查极限,我认为打印的条件是不正确的。当limit=0时,它应该打印。

谢谢--我醒着的时候都傻眼了。

 
一般来说,对历史数据的分析没有发现错误。
原因: