测试 "CopyTicks"。 - 页 19 1...121314151617181920212223242526...47 新评论 fxsaber 2016.09.30 19:16 #181 1434 - 平均需要1毫秒来获得CopyTicks已经上传的1000个刻度。缓慢,似乎是这样。要求TRADE0tic与之前收到的最后一个tick的from_msc。我得到了3个刻度,但在0.3-0.9毫秒内!"。- 现在非常慢。 fxsaber 2016.10.01 06:05 #182 fxsaber:强烈地记录了上面的代码,并想出了原因。如果CopyTicks (from > 0)在最新鲜的一个之前得到ticks,它可以跳过一些。 服务台的一个非常重要的答复。关于最初的问题--下一次调用的CopyTicks可以为同一时期提供更多的ticks。情况确实如此。问题是,交易所的数据流bid/ask和flipper/volume是不同的数据流,它们在交易所方面已经不同步了。正因为如此,有些情况下,首先是时间为12:12:12.300的买入/卖出,随后是时间为12:12:12.299的翻牌/成交量。相应地,请求自最后一个tick(12:12:12.300)以来的数据,你将不会得到12:12:12.299的新翻页。PS.终端保存并发送按时间排序的滴答声。也就是说,给CopyTicks的时间序列总是在增加。有两个流的蜱虫接收 - 信息和交易。所有的都是一个合成的联盟(似乎是在终端方面),这就是为什么可能会发生这样的错误。正是因为有了合成,才有了这样的词汇斯拉瓦。调用CopyTicks后的初始tick记录将不包含零,而是所要求的时间点上的bid、ask和last的当前值。 因此,在与所有蜱虫打交道时,你需要清楚地认识到你正在处理的是什么。也有可能是打勾的旗号被合成了。我希望对这些问题有充分的具体说明。如果CopyTicks工作正常的话,在磁带上应该不会出现这个问题。我认为,《帮助》将得到非常认真的补充。 [删除] 2016.10.01 10:48 #183 fxsaber: 你可以自己添加任何重载。 我可以做很多,你可以做很多,其他程序员也可以做很多,但希望开发人员更了解 "填塞",并能创造快速算法来获得必要的刻度。 prostotrader 2016.10.03 12:55 #184 测试了带有COPY_TICKS_TRADE标志的CopyTicks。没有区别。2016.10.03 15:50:48.507 Check_ticks (RTS-12.16,M1) History ticks = 9 2016.10.03 15:50:48.507 Check_ticks (RTS-12.16,M1) Dynamic ticks = 9 2016.10.03 15:50:48.956 Check_ticks (RTS-12.16,M1) History ticks = 11 2016.10.03 15:50:48.956 Check_ticks (RTS-12.16,M1) Dynamic ticks = 11 2016.10.03 15:50:49.184 Check_ticks (RTS-12.16,M1) History ticks = 12 2016.10.03 15:50:49.184 Check_ticks (RTS-12.16,M1) Dynamic ticks = 12 2016.10.03 15:50:49.510 Check_ticks (RTS-12.16,M1) History ticks = 14 2016.10.03 15:50:49.511 Check_ticks (RTS-12.16,M1) Dynamic ticks = 14 2016.10.03 15:50:51.568 Check_ticks (RTS-12.16,M1) History ticks = 15 2016.10.03 15:50:51.568 Check_ticks (RTS-12.16,M1) Dynamic ticks = 15 2016.10.03 15:50:51.627 Check_ticks (RTS-12.16,M1) History ticks = 16 2016.10.03 15:50:51.627 Check_ticks (RTS-12.16,M1) Dynamic ticks = 16 2016.10.03 15:50:53.143 Check_ticks (RTS-12.16,M1) History ticks = 19 2016.10.03 15:50:53.143 Check_ticks (RTS-12.16,M1) Dynamic ticks = 19 2016.10.03 15:50:54.514 Check_ticks (RTS-12.16,M1) History ticks = 27 2016.10.03 15:50:54.514 Check_ticks (RTS-12.16,M1) Dynamic ticks = 26 2016.10.03 15:50:54.542 Check_ticks (RTS-12.16,M1) History ticks = 27 2016.10.03 15:50:54.542 Check_ticks (RTS-12.16,M1) Dynamic ticks = 27 2016.10.03 15:50:54.847 Check_ticks (RTS-12.16,M1) History ticks = 30 2016.10.03 15:50:54.847 Check_ticks (RTS-12.16,M1) Dynamic ticks = 30 2016.10.03 15:50:57.052 Check_ticks (RTS-12.16,M1) History ticks = 31 2016.10.03 15:50:57.052 Check_ticks (RTS-12.16,M1) Dynamic ticks = 31 2016.10.03 15:50:57.301 Check_ticks (RTS-12.16,M1) History ticks = 32 2016.10.03 15:50:57.301 Check_ticks (RTS-12.16,M1) Dynamic ticks = 32 2016.10.03 15:51:00.498 Check_ticks (RTS-12.16,M1) History ticks = 44 2016.10.03 15:51:00.498 Check_ticks (RTS-12.16,M1) Dynamic ticks = 44 附加的文件: Check_ticks.mq5 41 kb fxsaber 2016.10.03 13:14 #185 prostotrader:测试了带有COPY_TICKS_TRADE标志的CopyTicks。没有区别。 关于交易、自动交易系统和策略测试器的论坛 神秘的股票指标 fxsaber, 2016.09.30 21:26 1434 - 问题没有得到解决。 fxsaber 2016.10.04 07:44 #186 fxsaber:强烈地记录了上面的代码,并想出了原因。如果CopyTicks (from > 0)得到的ticks是最新鲜的,它可能会跳过一些。例子。要求的ticks与从=2016.09.29 11:05:55.564。得到了三个点的答复一段时间后,我从远处请求查看滴答历史,得到了一个滴答,而CopyTicks之前错过了这个滴答。这样的虫子!似乎是平行写入和读出tick数据库的一些冲突。 1434是TRADE-类型的相同错误。复制专家顾问#include <TypeToBytes.mqh> // https://www.mql5.com/ru/code/16280 long LastTime = 0; // time_msc-время последнего тика (самого свежего), полученного из истории int Count = 0; // Количество тиков в последенем запросе, у которых time_msc == LastTime // Возвращает свежие тики, пришедшие после предыдущего вызова int GetFreshTicks( MqlTick &Ticks[], const uint flags = COPY_TICKS_TRADE, const uint count = 100000 ) { int Res = 0; MqlTick NewTicks[]; const int NewAmount = CopyTicks(Symbol(), NewTicks, flags, LastTime, count); if ((NewAmount > 0) && (Count < NewAmount)) { Res = ArrayCopy(Ticks, NewTicks, 0, Count); // Взяли крайнее время из текущей истории LastTime = Ticks[Res - 1].time_msc; Count = 1; // Находим (Count) в текущей истории количество тиков со временем LastTime for (int i = Res - 2; i >= 0; i--) { if (Ticks[i].time_msc < LastTime) break; Count++; } } return(Res); } string GetTickFlag( uint tickflag ) { string flag = ""; #define TICKFLAG_MACRO(A) flag += ((bool)(tickflag & TICK_FLAG_##A)) ? " TICK_FLAG_" + #A : ""; TICKFLAG_MACRO(BID) TICKFLAG_MACRO(ASK) TICKFLAG_MACRO(LAST) TICKFLAG_MACRO(VOLUME) TICKFLAG_MACRO(BUY) TICKFLAG_MACRO(SELL) #undef TICKFLAG_MACRO if (flag == "") flag = " FLAG_UNKNOWN (" + (string)tickflag + ")"; return(flag); } #define TOSTRING(A) " " + #A + " = " + (string)Tick.A string TickToString( const MqlTick &Tick ) { return(TOSTRING(time) + "." + (string)IntegerToString(Tick.time_msc %1000, 3, '0') + TOSTRING(bid) + TOSTRING(ask) + TOSTRING(last)+ TOSTRING(volume) + GetTickFlag(Tick.flags)); } #define TOSTRING2(A) #A + " = " + (string)(A) + " " template <typename T> bool ArrayEqual( const T &Array1[], const T &Array2[] ) { const int Amount = MathMin(ArraySize(Array1), ArraySize(Array2)); bool Res = (Amount > 0); if (Res) for (int i = 0; i < Amount; i++) if (_R(Array1[i]) != Array2[i]) // https://www.mql5.com/ru/code/16280 { Print(TOSTRING2(i) + TOSTRING2(ArraySize(Array1)) + TOSTRING2(ArraySize(Array2))); Print(TOSTRING2(TickToString(Array1[i])) + "\n" + TOSTRING2(TickToString(Array2[i])) + "\n"); Print(TOSTRING2(TickToString(Array1[i - 1])) + "\n" + TOSTRING2(TickToString(Array2[i - 1])) + "\n"); Res = false; ExpertRemove(); break; } return(Res); } void OnTick( void ) { static bool FirstRun = true; static MqlTick PrevTicks[]; if (FirstRun) { LastTime = TimeCurrent() * 1000; Count = 0; FirstRun = false; } MqlTick Ticks[]; // Взяли свеженькие тики const int Amount = GetFreshTicks(Ticks); ArrayCopy(PrevTicks, Ticks, ArraySize(PrevTicks)); if (ArraySize(PrevTicks) > 0) { MqlTick NewTicks[]; // Взяли историю тиков Print(CopyTicks(_Symbol, NewTicks, COPY_TICKS_TRADE, PrevTicks[0].time_msc, 1000000)); // Проверка на совпадение собираемой истории с самой историей Print(ArrayEqual(NewTicks, PrevTicks) ? "Equal" : "Not Equal"); } } 结果2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) Not Equal 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) ExpertRemove() function called 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array2[i-1]) = time = 2016.10.04 10:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4 TICK_FLAG_LAST TICK_FLAG_VOLUME TICK_FLAG_BUY 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array1[i-1]) = time = 2016.10.04 10:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4 TICK_FLAG_LAST TICK_FLAG_VOLUME TICK_FLAG_BUY 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array2[i]) = time = 2016.10.04 10:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4 TICK_FLAG_LAST TICK_FLAG_VOLUME TICK_FLAG_BUY 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array1[i]) = time = 2016.10.04 10:37:08.773 bid = 99690.0 ask = 99700.0 last = 99690.0 volume = 1 TICK_FLAG_LAST TICK_FLAG_VOLUME TICK_FLAG_SELL 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) i = 144 ArraySize(Array1) = 145 ArraySize(Array2) = 146 2016.10.04 10:36:17.743 Test13 (RTS-12.16,M1) 145 2016.10.04 10:36:16.768 Test13 (RTS-12.16,M1) Equal收集到的TRADE线程的实时tick历史不包含时间为2016.10.04 10:37:08.773的tick,该tick出现在历史的后期。这与我上面所说的 有些不一致。问题不仅在于合成的 "全流通",还在于直接的 "贸易"。 fxsaber 2016.10.04 09:07 #187 fxsaber: 1434是TRADE-类型的相同错误。复制的顾问 我道歉,这是我严重的疏忽。 fxsaber 2016.10.04 09:16 #188 fxsaber:1434 - 平均需要1毫秒来获得CopyTicks已经上传的1000个刻度。缓慢,似乎是这样。要求TRADE0tic与之前收到的最后一个tick的from_msc。我得到了3个刻度,但在0.3-0.9毫秒内!"。- 现在非常慢。相关的!没有办法加快速度? fxsaber 2016.10.04 11:15 #189 我想借此机会感谢开发人员对CopyTicks的工作!我不能说CopyTicks的工作绝对正确,但我设法完美地与磁带合作,并深入了解CopyTicks。不是要重新发明轮子,你可以在这里 和这里 看到基于磁带写tick指标的微调例子。 fxsaber 2016.10.11 17:23 #190 从_时间到_时间获取刻度的最佳(最快)算法是什么? 1...121314151617181920212223242526...47 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
1434 - 平均需要1毫秒来获得CopyTicks已经上传的1000个刻度。缓慢,似乎是这样。
要求TRADE0tic与之前收到的最后一个tick的from_msc。我得到了3个刻度,但在0.3-0.9毫秒内!"。- 现在非常慢。
强烈地记录了上面的代码,并想出了原因。如果CopyTicks (from > 0)在最新鲜的一个之前得到ticks,它可以跳过一些。
关于最初的问题--下一次调用的CopyTicks可以为同一时期提供更多的ticks。
情况确实如此。问题是,交易所的数据流bid/ask和flipper/volume是不同的数据流,它们在交易所方面已经不同步了。
正因为如此,有些情况下,首先是时间为12:12:12.300的买入/卖出,随后是时间为12:12:12.299的翻牌/成交量。
相应地,请求自最后一个tick(12:12:12.300)以来的数据,你将不会得到12:12:12.299的新翻页。
PS.终端保存并发送按时间排序的滴答声。也就是说,给CopyTicks的时间序列总是在增加。
有两个流的蜱虫接收 - 信息和交易。所有的都是一个合成的联盟(似乎是在终端方面),这就是为什么可能会发生这样的错误。
正是因为有了合成,才有了这样的词汇
调用CopyTicks后的初始tick记录将不包含零,而是所要求的时间点上的bid、ask和last的当前值。
如果CopyTicks工作正常的话,在磁带上应该不会出现这个问题。
我认为,《帮助》将得到非常认真的补充。
你可以自己添加任何重载。
测试了带有COPY_TICKS_TRADE标志的CopyTicks。
没有区别。
测试了带有COPY_TICKS_TRADE标志的CopyTicks。
没有区别。
关于交易、自动交易系统和策略测试器的论坛
神秘的股票指标
fxsaber, 2016.09.30 21:26
1434 - 问题没有得到解决。
强烈地记录了上面的代码,并想出了原因。如果CopyTicks (from > 0)得到的ticks是最新鲜的,它可能会跳过一些。
例子。
要求的ticks与从=2016.09.29 11:05:55.564。得到了三个点的答复
一段时间后,我从远处请求查看滴答历史,得到了一个滴答,而CopyTicks之前错过了这个滴答。
这样的虫子!
似乎是平行写入和读出tick数据库的一些冲突。
收集到的TRADE线程的实时tick历史不包含时间为2016.10.04 10:37:08.773的tick,该tick出现在历史的后期。
这与我上面所说的 有些不一致。问题不仅在于合成的 "全流通",还在于直接的 "贸易"。
1434是TRADE-类型的相同错误。复制的顾问
1434 - 平均需要1毫秒来获得CopyTicks已经上传的1000个刻度。缓慢,似乎是这样。
要求TRADE0tic与之前收到的最后一个tick的from_msc。我得到了3个刻度,但在0.3-0.9毫秒内!"。- 现在非常慢。
相关的!没有办法加快速度?
我想借此机会感谢开发人员对CopyTicks的工作!
我不能说CopyTicks的工作绝对正确,但我设法完美地与磁带合作,并深入了解CopyTicks。
不是要重新发明轮子,你可以在这里 和这里 看到基于磁带写tick指标的微调例子。