mql5语言的特点、微妙之处以及技巧 - 页 107 1...100101102103104105106107108109110111112113114...247 新评论 TheXpert 2018.10.18 07:50 #1061 fxsaber:可能是指单次传递可以持续超过~50天的时间不,斯拉瓦得到了它的权利,并说了它。 Nikolai Semko 2018.10.18 09:22 #1062 Nikolai Semko: 测试仪中的时间密度是完全不同的。这是不可能的。我错了。,我确信在测试器中GetTickCount() 函数是根据测试时间来模拟数值的。 非常奇怪,不符合逻辑。给我的惊喜。这意味着GetTickCount()在测试器中只是 "冻结 "了。 Slava 2018.10.18 09:28 #1063 Nikolai Semko: 我错了。,我确信测试器中的GetTickCount()函数是根据测试的时间来模拟数值的。非常奇怪,不符合逻辑。给我的惊喜。也就是说,应该理解为GetTickCount()只是在测试器中 "冻结 "了。为什么不符合逻辑呢? 在一次调用OnTick、OnCalculate、OnInit、OnDeinit等是很合理的。计算结果在严重程度上会有很大不同。 Nikolai Semko 2018.10.18 09:35 #1064 TheXpert: 不,斯拉瓦说对了,说了。不,他没有。 如果计划开始后正好过了50天,那么差额将显示为几个小时。 但是如果你使用GetMicrosecondCount()而不是GetTickCount(),那么不溢出的时间将是584542年而不是50天 ZY 更确切地说,如果你考虑公历的话,是583081年)) Nikolai Semko 2018.10.18 09:40 #1065 Slava: 为什么会不符合逻辑呢?在对OnTick、OnCalculate、OnInit、OnDeinit等的单次调用中是很合理的。计算结果在严重程度上会有很大不同。嗯,是的,对于测量一些函数或代码块的计算执行时间来说,这才是合理的。GetTickCount()和GetMicrosecondCount() 函数在测试器中对其他方面是无用的,例如,测量一些事件之间的时间。 Nikolai Semko 2018.10.18 09:43 #1066 此后,所有试验品 的起源都很清楚。)) TheXpert 2018.10.18 09:48 #1067 Nikolai Semko: 不,不是的。 如果从节目开始到现在正好过了50天,那么差异将显示为几个小时。 这样的间隔是无法测量的 说实话,即使考虑到这种情况,如何考虑--我也不知道。 Nikolai Semko 2018.10.18 09:53 #1068 TheXpert: 这种差距是无法衡量的说实话,即使考虑到这种情况,如何考虑--我也不知道。不,你当然不必担心这个问题。50天--它真的超越了实际应用。如果你真的需要测试超过50天,最好还是使用GetTickCount(),因为它更容易,只是有溢出控制(会有额外的变量)。 Nikolai Semko 2018.10.18 10:09 #1069 事实上,测试器中的本地时间 话题对公平竞争是非常有毒的。这都是白色的谎言。 如果我是MQ,我会关闭所有这些漏洞,以确定当地时间,因为在测试器中不需要,只是为了那些易受骗的新晋交易者。 好吧,或者至少从这个主题和其他主题中删除这个话题,如果可以的话。 fxsaber 2018.10.18 10:25 #1070 尼古拉-森科。事实上,在测试器中提出的当地时间的话题对公平竞争是非常有毒的。这都是白帽子。 如果我是MQ,我会关闭所有这些定义本地时间的漏洞,因为在测试器中没有必要,只是为了愚弄那些易受骗的新交易者。 好吧,或者至少把这个话题从这个线程和其他线程上拿下来,如果可以的话。任何欺骗行为都不能由主题来承担。至于实际应用,我在KB中使用它。这是很方便的。 1...100101102103104105106107108109110111112113114...247 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
可能是指单次传递可以持续超过~50天的时间
不,斯拉瓦得到了它的权利,并说了它。
测试仪中的时间密度是完全不同的。这是不可能的。
我错了。
,我确信在测试器中GetTickCount() 函数是根据测试时间来模拟数值的。
非常奇怪,不符合逻辑。给我的惊喜。这意味着GetTickCount()在测试器中只是 "冻结 "了。
我错了。
,我确信测试器中的GetTickCount()函数是根据测试的时间来模拟数值的。
非常奇怪,不符合逻辑。给我的惊喜。也就是说,应该理解为GetTickCount()只是在测试器中 "冻结 "了。
为什么不符合逻辑呢?
在一次调用OnTick、OnCalculate、OnInit、OnDeinit等是很合理的。计算结果在严重程度上会有很大不同。
不,斯拉瓦说对了,说了。
不,他没有。
如果计划开始后正好过了50天,那么差额将显示为几个小时。
但是如果你使用GetMicrosecondCount()而不是GetTickCount(),那么不溢出的时间将是584542年而不是50天
ZY 更确切地说,如果你考虑公历的话,是583081年))
为什么会不符合逻辑呢?
在对OnTick、OnCalculate、OnInit、OnDeinit等的单次调用中是很合理的。计算结果在严重程度上会有很大不同。
嗯,是的,对于测量一些函数或代码块的计算执行时间来说,这才是合理的。GetTickCount()和GetMicrosecondCount() 函数在测试器中对其他方面是无用的,例如,测量一些事件之间的时间。
不,不是的。
如果从节目开始到现在正好过了50天,那么差异将显示为几个小时。
这样的间隔是无法测量的
说实话,即使考虑到这种情况,如何考虑--我也不知道。
这种差距是无法衡量的
说实话,即使考虑到这种情况,如何考虑--我也不知道。
不,你当然不必担心这个问题。50天--它真的超越了实际应用。如果你真的需要测试超过50天,最好还是使用GetTickCount(),因为它更容易,只是有溢出控制(会有额外的变量)。
事实上,测试器中的本地时间 话题对公平竞争是非常有毒的。这都是白色的谎言。
如果我是MQ,我会关闭所有这些漏洞,以确定当地时间,因为在测试器中不需要,只是为了那些易受骗的新晋交易者。
好吧,或者至少从这个主题和其他主题中删除这个话题,如果可以的话。
事实上,在测试器中提出的当地时间的话题对公平竞争是非常有毒的。这都是白帽子。
如果我是MQ,我会关闭所有这些定义本地时间的漏洞,因为在测试器中没有必要,只是为了愚弄那些易受骗的新交易者。
好吧,或者至少把这个话题从这个线程和其他线程上拿下来,如果可以的话。
任何欺骗行为都不能由主题来承担。至于实际应用,我在KB中使用它。这是很方便的。