打勾的故事 - 页 10

 
Vasiliy Sokolov:
在MT5中,时间是一个真正的问题。首先,系统的日期时间类型 分辨率太低,按照现代标准,一秒钟是一个永恒的时间。第二,事件的到达与时间无关。假设我们在OnBookEvent中得到一个新的玻璃的截图,它指的是什么时间?我们是否应该用服务器的最后已知 时间来获取TimeCurrent?如果最后已知的服务器时间是在一分钟前更新的呢?

他们不太可能在3000年之前改变日期时间。

последняя дата datetime 3001.01.01 00:00:00 | 32535216000

做一个包装袋要容易得多。

struct millisekdatetime
  {
   datetime time;
   ushort millisek;
  };
 
Tapochun:
我不需要一个指标。而且我不需要模式差异。告诉我,你是否观察到当从一个模式中请求不同的数量(例如,2000和10000)时,相同的刻度线的差异。
卡尔普托夫-弗拉基米尔
现在我明白了。我需要检查一下...

Ghjdt检查过。所以:在一个相同的工具中,在一个相同的tick接收模式下(我找的是COPY_TICKS_INFO 模式 --只有买入和卖出),在不同的tick请求深度下,我们会收到不同的tick流。 专家顾问的附件文件(1.41版)明确显示了这种行为的原因。

1

当要求1500时,它返回1500点,当要求10000时,它返回4691点。一般来说,如果它返回的点数超过2000,那么回馈历史的模式就会改变。

附加的文件:
CopyTicks.mq5  4 kb
 
Karputov Vladimir:

Ghjdt检查过。所以:在一个相同的代码,一个相同的tick接收模式(我检查了COPY_TICKS_INFO 模式 --只有买入和卖出),在不同的tick请求深度下,收到的tick流是不同的。 专家顾问(1.41版)的附件文件明确显示了这种行为的原因。

当要求1500时,它返回1500点,当要求10000时,它返回4691点。一般来说,如果返回的点数超过2000,那么历史返回模式就会改变。

有了,太好了,我也有了。我给servicedesk写了信,我们会等待。
 
Tapochun:
这里,太好了,我也有。我写信给serviced,我们将等待。

我注意到一个有趣的特点。我用一个新的工具运行了 我之前帖子中描述的EA (它还没有请求tick历史,因此还没有在磁盘上创建tick历史文件),发现一开始它在请求2000个tick时返回了大约200个tick。但渐渐地,随着每一次嘀嗒声的响起,返回的嘀嗒声越来越多--感觉就像我在这里写的时候,网上的历史被添加到了最初的200次嘀嗒声中。

新增:附EA 1.42版 - 纠正了第一次运行时的区间出场错误。

附加的文件:
CopyTicks.mq5  4 kb
 
升级到新构建的1190。在新版本中重新编译了EA。在测试者中,CopyTicks()没有得到刻度线--错误4014。
 
Karputov Vladimir:

我注意到一个有趣的特点。我用一个新的工具运行了 我以前的帖子中描述的EA (它还没有请求tick历史,因此还没有在磁盘上创建tick历史文件),发现一开始它在请求2000个tick时返回了大约200个tick。但渐渐地,随着每一次嘀嗒声的响起,返回的嘀嗒声越来越多--感觉就像我在这里写的时候,网上的历史被添加到了最初的200次嘀嗒声中。

新增:附EA 1.42版 - 修复了第一次运行时的区间退出错误。

是的,雷纳特注意到,蜱虫正在被加载。所以我们应该检查是否有-1的回报(至少是)。相反,COPY_TICKS_INFO模式允许分析器检查返回的ticks与请求的ticks是否相等,即使它不是那么重要。它仍然会返回较少。
 
Tapochun:
是的,雷纳特指出,蜱虫正在被接走。所以,有必要检查-1(至少)。而在COPY_TICKS_INFO模式下,你可以检查返回的数量是否等于请求的数量,即使你不这样做--也是无用的。
好吧,在星期一之前我无法检查任何有虱子的东西。我将处理其他事情。
 

现在试了试请求蜱虫--在离线图表上。不管要求的模式和点数如何,结果都差不多:完全没有出价(所有点数的出价=0)。

 
Karputov Vladimir:
好吧,反正在周一之前,你都无法相信任何有抽搐的事情。我会做别的事情。
为什么?如果你下载了一个指标,有一个很棒的按钮可以刷新。而且没有人取消剧本。
 
请再次解释。现在可用的蜱虫史的深度是多少?历史记录是否从服务器上下载,即不需要积累?测试器是如何工作的,它是使用tick模拟 还是tick历史?