MqlTick ExtArr[2048]; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ voidOnTick() { ulong from =(TimeTradeServer()-1200)*1000; ulong ticks =GetMicrosecondCount(); int records=CopyTicks(_Symbol,ExtArr,COPY_TICKS_INFO,from,2048);
ticks=GetMicrosecondCount()-ticks; Print("Time: ",ticks," msc for ",records," records"); }
下面是以微秒为单位的输出:在过去20分钟里,2048个INFO点的每个样本有95微秒的输出
2016.10.1814:15:38.673 TEST (USDCHF,M1) Time: 95 msc for1206 records
这与你所说的几十毫秒有很大的不同。那是因为你没有测量CopyTicks。
收市后的刹车
MqlTick ExtArr[2048]; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ voidOnStart() { ulong from =(TimeCurrent()-1200)*1000; ulong ticks =GetMicrosecondCount(); int records=CopyTicks(_Symbol,ExtArr,COPY_TICKS_INFO,from,2048);
ticks=GetMicrosecondCount()-ticks; Print("Time: ",ticks," msc for ",records," records"); }
结果
2016.10.2900:31:10.952 Test (GBPUSD,M1) Time: 85 msc for1333 records 2016.10.2900:31:05.435 Test (EURCHF,M1) Time: 15283 msc for874 records 2016.10.2900:31:03.960 Test (EURCHF,M1) Time: 11629 msc for874 records 2016.10.2900:31:02.128 Test (EURCHF,M1) Time: 10127 msc for874 records 2016.10.2900:31:00.332 Test (EURCHF,M1) Time: 7318 msc for874 records 2016.10.2900:30:52.049 Test (EURUSD,M1) Time: 51 msc for862 records
Если по какой-то причине возникает ошибка контроля объемов на свече после 10.00 в реальном времени, то эта же ошибка возникает и на истории. Однако! Если изменить сервер - ошибка на истории пропадает.
或者是你折磨了他?:)
他是。他的情况真的很糟糕。我不得不佩服他--他确实陷入了昏迷,但很少。
我写了一个很好的刻度线指标。我懒得去调试罕见的故障。
他是。他的情况真的很糟糕。我不得不佩服他--他确实陷入了昏迷,但很少。
我写了一个很好的刻度线指标。我懒得去调试罕见的故障。
每次都能设法把所有的小数点均匀地装进蜡烛里吗?
已添加。
在有数量检查的COPY_TICKS_TRADE模式下。
每次都能设法把所有的小数点均匀地装进蜡烛里吗?
已添加。
在有数量检查的COPY_TICKS_TRADE模式下。
我有一个稍微不同的。比如 "没有同行",等等等等。
我不认为在性能方面是这样,因为它承诺在下一个版本中会有明显的改善。
我有一个稍微不同的。比如 "无与伦比",等等,等等。
我不认为在性能方面是这样,因为它承诺在下一个版本中会有明显的改善。
这与性能无关...有这样的情况,比如说现在。
该指标收集刻度线并通过它们来计算交易量。然后它将这个体积与volume[]进行比较。
而且在几种情况下都有错误。
有时一天中第一支蜡烛的成交量计算不正确(与检查的成交量不一致)。
有时每点的成交量计算正确,但成交量却返回不正确的值。
3.有时每点的成交量计算不正确,而成交量则返回一个不正确的值。
最有趣的是,如果历史上出现错误1、2或3,在重新编译指标后,错误并没有消失。而在连接到另一个服务器的情况下,它就消失了。
简而言之,奇迹还没有结束。
如果这个帖子会被开发人员阅读并想了解--请直接到 "服务台",我将提供所有来源。
这就是你应该测试CopyTicks的方式。
//+------------------------------------------------------------------+
//| |
//+------------------------------------------------------------------+
void OnTick()
{
ulong from =(TimeTradeServer()-1200)*1000;
ulong ticks =GetMicrosecondCount();
int records=CopyTicks(_Symbol,ExtArr,COPY_TICKS_INFO,from,2048);
ticks=GetMicrosecondCount()-ticks;
Print("Time: ",ticks," msc for ",records," records");
}
下面是以微秒为单位的输出:在过去20分钟里,2048个INFO点的每个样本有95微秒的输出
收市后的刹车
//+------------------------------------------------------------------+
//| |
//+------------------------------------------------------------------+
void OnStart()
{
ulong from =(TimeCurrent()-1200)*1000;
ulong ticks =GetMicrosecondCount();
int records=CopyTicks(_Symbol,ExtArr,COPY_TICKS_INFO,from,2048);
ticks=GetMicrosecondCount()-ticks;
Print("Time: ",ticks," msc for ",records," records");
}
结果
2016.10.29 00:31:05.435 Test (EURCHF,M1) Time: 15283 msc for 874 records
2016.10.29 00:31:03.960 Test (EURCHF,M1) Time: 11629 msc for 874 records
2016.10.29 00:31:02.128 Test (EURCHF,M1) Time: 10127 msc for 874 records
2016.10.29 00:31:00.332 Test (EURCHF,M1) Time: 7318 msc for 874 records
2016.10.29 00:30:52.049 Test (EURUSD,M1) Time: 51 msc for 862 records
这似乎只发生在欧元兑美元上。但只要我们开始为欧元兑美元抽出报价。只要脚本开始在EURSD上运行几十毫秒。这种放缓是在市场收盘后开始的。在市场关闭之前,一切都快得多。
亲爱的开发者们!CopyTicks()的问题,特别是蜡烛上的量的同步(将蜡烛的所有tick量堆积在一个蜡烛中,并与该蜡烛的volume[]进行比较)。它继续说。
现在我们又有了2个错误。
1.开烛的音量控制的稳定误差(10.00)。我在RTS、SBRF、Si(都在-12.16)上测试。在这些符号上都有错误!
2.如果由于某种原因,在实时10点之后的蜡烛图上出现了音量控制的错误,在历史上也会出现同样的错误。然而!如果你改变了服务器,历史上的错误就消失了。
例子到前面的帖子(关于错误2)。
2016.10.31 12:13:43.699 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:06 пройден! Контрольная сумма = 4103 (2236+1867)
2016.10.31 12:13:43.699 (Si-12.16,M1) VolumeControl: ОШИБКА на свече 2016.10.31 10:07! Сумма объемов на покупку = 1074, сумма объемов на продажу = 3917, контрольная сумма (покупки+продажи) = 5009
2016.10.31 12:13:43.699 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:08 пройден! Контрольная сумма = 3121 (1479+1642)
2016.10.31 12:13:43.699 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:09 пройден! Контрольная сумма = 3760 (1046+2714)
这是在改变服务器之前。下面是更换服务器后的日志。
2016.10.31 12:18:12.109 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:06 пройден! Контрольная сумма = 4103 (2236+1867)
2016.10.31 12:18:12.109 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:07 пройден! Контрольная сумма = 5009 (1082+3927)
2016.10.31 12:18:12.109 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:08 пройден! Контрольная сумма = 3121 (1479+1642)
2016.10.31 12:18:12.110 (Si-12.16,M1) VolumeControl: Контроль свечи 2016.10.31 10:09 пройден! Контрольная сумма = 3760 (1046+2714)
这就是,本地化的 "BORDER"!我自己不在这里画控件,括号里的数值不调整,我不需要。但是,有一个错误,可以通过改变服务器来解决这个问题!
这是来自历史控制的日志(启动指标/点击 "刷新 "按钮时)。
现在对第一号错误进行评论。
开市后一段时间(现在已经过了大约40分钟)。随着指标的全面重新计算--控制10.00点的蜡烛是没有错误的!即使不切换服务器。就像有人把历史资料下载到服务器上一样。
关于2号错误的另一个观察。
Если по какой-то причине возникает ошибка контроля объемов на свече после 10.00 в реальном времени, то эта же ошибка возникает и на истории. Однако! Если изменить сервер - ошибка на истории пропадает.