测试 "CopyTicks"。 - 页 16

新评论
 
fxsaber:

我的理解是否正确，一个条形图的刻度线量 应该等于该条形图中的COPY_TICKS_ALL刻度线的数量？

我没有用MQL写，我想问一下会比较快。交易所的哪种工具传统上有最高的交易量，哪种工具有最高的tick量？

没有。

滴答量反映了改变条形图的滴答数量。如果一个条形图是由翅片构成的，那么买入和卖出就不会形成条形图，因此不计入tick量。

 
fxsaber:
如果我用定时器（50ms）下载几十个仪器的新刻度，CopyTicks的内部缓存、内存、生产力会发生什么变化？

缓存不可能发生什么。每个角色都有自己的刻度线缓存，其中包含多达65,000个最后的刻度线。

如果你每隔50毫秒查询一次最后的刻度线，它们肯定会从缓存中得到，而不需要对磁盘上的刻度线数据库进行额外查询。

监测你自己的表现。追踪CPU消耗情况

 
Slawa:

滴答量反映了改变条形图的滴答数量。如果一个条形图是以翻牌为基础的，出价和要价不会形成一个条形图，因此，不包括在tick volume中。

COPY_TICKS_TRADE也不会全部打出tick volume？例如，当炒房者的价格没有变化时

关于交易、自动交易系统和测试交易策略的论坛

Metatrader 5中的交易功能区

fxsaber, 2016.09.13 09:39

这是一块饲料。告诉我，我是否正确理解了截图中绿框中强调的情况？

有人提出了一个市场要求，正好是10手。此时，相应的最佳帮派由按时间顺序排列的限价出价组成，拍品为1，1，1，1，3，2，1。在市场上，这帮人（98340）可能还有其他出价，但从时间上看，他们的出价要比上述那些人晚。

这是否正确？


 
Slawa:

缓存不可能发生什么。每个角色都有自己的刻度线缓存，其中包含多达65,000个最后的刻度线。

如果你每隔50毫秒查询一次最新的ticks，它们肯定会从缓存中出来，而不需要额外查询磁盘上的ticks数据库。

监测你自己的表现。密切关注CPU的消耗情况

如果我设置From = 0，那么它就是从缓存中复制。如果From是好的，那么它是如何实施的？

在最近的测试版本中，CopyTicks的错误是否会被修复？

 
勾股量 是一种粗略的说法吗？一个在交换中基本没有意义的数字。没有办法刻意去使用它。它是垃圾。
 
fxsaber:

如果我设置From = 0，那么缓存就被复制了。如果From是好的，那么它是如何在那里实施的？

在未来的测试版中，CopyTicks的错误是否会被修复？

如果from在缓存中，所有的ticks都将从缓存中获取。

现在我们只是在处理CopyTicks。复制了一个案例，当刻度线的数量与OnCalculate调用 的数量不一致时（一个刻度线在条形边界上来回 "行走"）。

 
Slawa:

现在我们要处理的是CopyTicks。复制了一个案例，当刻度线的数量与OnCalculate调用 的数量不一致时（一个刻度线 在条形边界来回移动）。

我的差距超过了一个刻度。然后是这个。

关于交易、自动交易系统和策略测试的论坛

交易所的指标缺少刻度线

fxsaber, 2016.09.16 16:31

在我看来，只是指标不应错过刻度线的立场似乎是模糊的。

例如，蜱虫以巨大的频率播放。比方说，每10ms。但OnCalculate的执行时间是15ms。

如果指标没有跳过刻度，系统就会挂起。


 
fxsaber:
我的差距超过了一个刻度。然后是这个。

如果有一个虱子，可能有两个或更多。我们已经发现了问题，现在我们正在调查它。

如果指标写得少，就不会有性能问题

 
Slawa:

如果指标写得少，就不会有性能问题

我就是这样举了一个经济性的例子--15ms。
 
fxsaber:
所以我举了一个经济性的例子--15ms。

15 ms -GetTickCount 的测量误差

让我们先把CopyTicks处理到最后，这样就不会有问题了。如果不在每个刻度上调用OnCalculate，我们就不能不做。

然后我们会思考。也许只有在MqlRates中发生变化时才调用OnCalculate--价格、价差或交易量。如果勾选没有引起变化，那么就不应该调用重新计算。有必要进行思考。

1...91011121314151617181920212223...47
新评论