错误、漏洞、问题 - 页 213

[Slava]

Olegts:

从图中可以看出，只有三个核心在工作，我见过不止一种情况，在测试过程中，参与工作的核心数量逐渐下降到零，之后所有的核心都一次开始工作，也就是出现了停机，为什么释放出来的核心不一次开始工作？

为了开始计算下一代，我们应该首先处理当前一代。必须完成当前一代的所有运行，以便选择最佳的运行，并在最佳运行之间进行遗传操作。只有这样，才能开始下一代的工作。

当还剩下一些缺失的结果来完成处理当前一代时，被释放的测试代理就没有工作了。

[Oleg Tsarkov]

stringo:

谢谢你

[Гребенев Вячеслав]

Virty:

在EventSetTimer( )中可以设置的最大时间是什么？

INT_MAX？ 我想不是。我不想自己去调查，而且帮助中也没有这个内容。

任何时间都可以在这里设置，但在测试器中，时间将以50天为模数。约4 220 000秒。

MQL5的质量让我失去了动力。

[Slava]

Virty:

这里可以使用任何时间，但在测试器中，时间将以50天为模数。约4 220 000秒。

MQL5的质量是令人沮丧的。

你最多可以设置2 147 483秒（相当于35 791分钟、596小时或24天）。这不是测试仪中处理定时器的方式。

反问。为什么要把定时器设置为24天？

[Гребенев Вячеслав]

stringo:

最多可以设置2,147,483秒（相当于35,791分钟，596小时或24天）。这不是测试仪中处理定时器的方式。

反问。为什么要把定时器设置为24天？

我希望开仓后在1秒到10年的时间内关闭仓位，这取决于一些东西。

我是这样试的

request.type_time=ORDER_TIME_SPECIFIED; // 该订单将在到期日之前有效。
request.expiration=1; /或者TimeCurrent()+time; (int time=1;)

不适用于秒。

用EventSetTimer( )绕过了这个问题。也限于24天。最重要的是，我没有想到计时器会出现如此混乱的情况。你应该被警告过。哦，好吧。

顺便问一下，计时器中的时间是真正的日历时间还是只是交易时间？换句话说，紧接着周末，计时器上显示的时间是多少？

[Andrey Sharov]

再次报告了一个终端和服务器之间部分失去通信的案例。建设360。没有收到报价，但关于时间和交易量的信息被更新。连接状态指示器上有一个带有灰色扇形的旋转圆圈。日志里有一些信息。

2010.11.29 18:03:03 交易 '630031' : 交易 #2107036 在1.55387买入0.10 GBPUSD 完成（基于订单 #2157432）。
2010.11.29 18:00:02 交易 '630031' : 交易 #2106895 在1.55341买入0.10 GBPUSD 完成（基于订单 #2157265）。
2010.11.29 17:07:49 网络'630031'：MetaQuotes-Demo上的授权
2010.11.29 17:07:47 网络 '630031': 失去与MetaQuotes-Demo的连接
2010.11.29 16:10:47 网络 '630031': 交易已被禁止 - 投资者模式
2010.11.29 16:10:47 网络'630031'：终端与MetaQuotes软件公司同步。
2010.11.29 16:10:47 网络 '630031': 授权于MetaQuotes-Demo
2010.11.29 16:10:45 网络 '630031': 失去与MetaQuotes-Demo的连接

请注意，在17:07:49之后，没有 "终端与MetaQuotes软件公司同步 "的信息，在同一时间有新的交易报告。

[Andrey Sharov]

Rosh:
Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.

给你。

测试系统（不管它是什么！）：Windows XP SP3, Pentium 4, 3GHz, 1.25Gb内存

所有的运行都是使用Alpari-Demo，GPBUSD M1，04.10.2010-05.11.2010（1521376点，34194条）在正常模式下进行的，每一个点，存款10000美元（顺便问一下，你从哪里得到1000000美元的存款？ 我的清单以100000结尾），杠杆1：100。我构建了一个专家顾问，利用Alpari-Demo账户的特殊性--零保证金--来简化其构建。对于每一个刻度，专家顾问在一个方向上打开一个0.1手的订单，直到它达到使用参数指定的交易量，其余的刻度被跳过。 因此，交易数量的影响被最小化（在所有测试运行中获得1个交易）。顺便说一下，在每次测试结束时，我们检查了形成Open XML格式的报告的大致时间（到目前为止还没有超过耐心的阈值）。测试者在测试结束时产生的交易没有被考虑在内（每次运行一个交易）。

因此。

第一个系列的测试从10个到100个交易，增量为10个，由于测试时间小--嘀嗒声生成时间从5359到6453，所以不值得关注。

下一个系列是从100到1000个交易，以100为增量（100的结果取自上一个系列）。

交易 时间，毫秒 总时间，毫秒 形成xlsx报告的大约时间，秒。 笔记 100 6359 6813 5 不到5秒 200 6172 6594 5 300 6875 7375 7 400 5734 6094 10 500 6109 6562 14 600 6281 6687 17 700 8016 8563 23 800 7281 7719 28 900 9047 9610 35 1000 8453 8812 44

总的来说是好的，但报告的生成问题开始出现了

[[删除]]

Ashes:

所有的运行都是在Alpari-Demo，GPBUSD M1，04.10.2010-05.11.2010（1521376点，34194条）的正常模式下进行的，每个点，存款10000美元（顺便问一下，你从哪里得到10000美元的存款？

这不是问题，所需金额可以手动输入。

[Andrey Sharov]

最后的系列（在这个硬件上的进一步测试对我来说太苛刻了；）从1000到10000，每步1000。

这时，罗什 质疑地提到的刹车出现了所有的光辉。

行业 时间，毫秒 总时间，毫秒 生成xlsx报告的大约时间，秒。 笔记 1000 8453 8812 44 2000 26750 27266 159 3000 60782 61141 355 ** 4000 125469 171391 480 超过480秒 ** 5000 414609 459281 没有数据 运行超过4000个交易时不生成报告 6000 600610 601094 没有数据 7000 648234 675576 648234 675576 无数据 ** 8000 1082437 1082796 1082437 1082796 无数据 9000 1465203 1508359 没有数据 10000 1988031 2012500 没有数据

用Rosh的话说， 你可以从图中看到，测试时间对RATE数量的依赖不是严格的线性关系。相反，它根本就不是线性的。

在5000和6000的结果可能有点高估，但可以看到一个趋势。

我想提醒你，这个结果是使用最简单的专家顾问获得的，实际上没有花时间进行任何分析，也没有使用指标；也就是说，在一个工作的EA中，结果会更糟糕。

作为比较。

在Windows 7机器上进行10000次交易的测试，英特尔奔腾双核E5400 @ 2.70 GHz, 2038 MB (PR111)花了472866ms。

鉴于上述情况，2010年锦标赛的一些候选人有可能因为15分钟的障碍和测试仪的特殊性而被不公正地淘汰（如果有很多交易）。

** - 在测试者结束时，有几次没有显示显示交易的符号图表。

[Andrey Sharov]

Interesting:
Это не проблема, нужная сумма может быть вбита руками.

谢谢你，我不知道。