mql5语言的特点、微妙之处以及技巧 - 页 107

新评论
 
fxsaber:

可能是指单次传递可以持续超过~50天的时间

不，斯拉瓦得到了它的权利，并说了它。

 
Nikolai Semko:

测试仪中的时间密度是完全不同的。这是不可能的。

我错了。
，我确信在测试器中GetTickCount() 函数是根据测试时间来模拟数值的。

非常奇怪，不符合逻辑。给我的惊喜。这意味着GetTickCount()在测试器中只是 "冻结 "了。

 
Nikolai Semko:

我错了。
，我确信测试器中的GetTickCount()函数是根据测试的时间来模拟数值的。

非常奇怪，不符合逻辑。给我的惊喜。也就是说，应该理解为GetTickCount()只是在测试器中 "冻结 "了。

为什么不符合逻辑呢？

在一次调用OnTick、OnCalculate、OnInit、OnDeinit等是很合理的。计算结果在严重程度上会有很大不同。

 
TheXpert:

不，斯拉瓦说对了，说了。

不，他没有。
如果计划开始后正好过了50天，那么差额将显示为几个小时。

但是如果你使用GetMicrosecondCount()而不是GetTickCount()，那么不溢出的时间将是584542年而不是50天
ZY 更确切地说，如果你考虑公历的话，是583081年))

 
Slava:

为什么会不符合逻辑呢？

在对OnTick、OnCalculate、OnInit、OnDeinit等的单次调用中是很合理的。计算结果在严重程度上会有很大不同。

嗯，是的，对于测量一些函数或代码块的计算执行时间来说，这才是合理的。GetTickCount()和GetMicrosecondCount() 函数在测试器中对其他方面是无用的，例如，测量一些事件之间的时间。

 
此后，所有试验品 的起源都很清楚。))
 
Nikolai Semko:

不，不是的。
如果从节目开始到现在正好过了50天，那么差异将显示为几个小时。

这样的间隔是无法测量的

说实话，即使考虑到这种情况，如何考虑--我也不知道。

 
TheXpert:

这种差距是无法衡量的

说实话，即使考虑到这种情况，如何考虑--我也不知道。

不，你当然不必担心这个问题。50天--它真的超越了实际应用。如果你真的需要测试超过50天，最好还是使用GetTickCount()，因为它更容易，只是有溢出控制（会有额外的变量）。

 

事实上，测试器中的本地时间 话题对公平竞争是非常有毒的。这都是白色的谎言。
如果我是MQ，我会关闭所有这些漏洞，以确定当地时间，因为在测试器中不需要，只是为了那些易受骗的新晋交易者。

好吧，或者至少从这个主题和其他主题中删除这个话题，如果可以的话。

 
尼古拉-森科。

事实上，在测试器中提出的当地时间的话题对公平竞争是非常有毒的。这都是白帽子。
如果我是MQ，我会关闭所有这些定义本地时间的漏洞，因为在测试器中没有必要，只是为了愚弄那些易受骗的新交易者。

好吧，或者至少把这个话题从这个线程和其他线程上拿下来，如果可以的话。

任何欺骗行为都不能由主题来承担。至于实际应用，我在KB中使用它。这是很方便的。

1...100101102103104105106107108109110111112113114...247
新评论