错误、漏洞、问题 - 页 433

[[删除]]

雷纳特，如果你能注意到SR中的124661号申请。

自6月13日以来，我一直在等待答复。

[Renat Fatkhullin]

voix_kas:

雷纳特，如果你能注意到SR中的124661号申请。

自6月13日以来，我一直在等待答复。

所以你已经不止一次得到了正确的答案。我已经再次回答了你。

[[删除]]

Renat:

所以你已经不止一次得到了正确的答案。再次回答了你。

我在这个申请中没有看到答案。其中最后一条评论是我在2011.06.21 09:25发表的（反复提醒问题的关联性）。

在此复制，以备不时之需。

我的理解是否正确，交易/订单的最低交易量/手数限制 只与开仓 有关？
它们是否 适用于导致关闭、增加、减少或逆转头寸 的交易/订单？
最低交易限额适用于上述所有五（5）种情况。
似乎所有可能的情况都有描述。或者除了这五（5）种情况外，还有其他情况吗？

[Renat Fatkhullin]

你已经被回答了两次，然后我回答了。

我将再次回答--是的，全面关闭不包括在数量限制规则中。

[Renat Fatkhullin]

papaklass:
我们是否在谈论提高MQL5的速度？

是的，代码优化的 意思正是如此。

[[删除]]

Renat:

你被回答了两次，然后我回答了。
我再回答一次--是的，全额平仓不受数量限制规则的限制。

雷纳特，不要误解我的意思。我重复我的问题不是为了撒娇，而是为了澄清它。
到目前为止，你和你的同事（在SD中）的答案涵盖了2种（两个） 情况：1）开仓 和2）完全平仓（可能ORDER_FILLING_AON 是强制性的）。
一个订单（交易）的执行可能会导致 至少三（3） 种其他 情况：增加、减少 或逆转头寸。
不幸的是，我在MQ的答案中找不到对这三种情况的任何明确 解释。:(

为了清楚起见，这里有一些例子（在 服务器的所有情况 下，最小手数=1.0；最小步数=0.1）。

例子#1 （位置缩短）。
我们有一个1.0的长仓。我们正试图完全关闭头寸（使用ORDER_FILLING_CANCEL）。我们发送1.0手的卖出指令。该订单被部分执行（0.9手）。
结果是，有一个0.1手的未平仓多头头寸。因此，我们可以得出结论，最小手数的要求并不适用于 缩短仓位 的情况。

例2（位置颠倒）。
我们有一个0.1手的多头头寸。我向服务器发送了0.2手的卖出订单。服务器会接受这个订单吗？(又没有达到最低地段要求）。

例3（增加职位）。
我们有一个0.1手的多头头寸。我向服务器发送一个0.1手的买入订单。

[Renat Fatkhullin]

voix_kas:

为了说明问题，这里有一些例子（在所有情况下，最小批量=1.0；最小步骤=0.1）。

例1 （空头头寸）。
我们有1.0手的多头头寸。我们正试图完全关闭头寸（使用ORDER_FILLING_CANCEL）。我们发送1.0手的卖出指令。该订单被部分执行（0.9手）。
结果是，有一个0.1手的未平仓多头头寸。因此，我们可以得出结论，最小手数的要求并不适用于 缩短仓位 的情况。

如果该仓位在0.9处部分平仓（在1.0处有一个订单），那么我们将不得不发送另一个订单以在0.1处平仓余额。

而如果订单是通过外部网关执行的，他们很有可能只一次性关闭整个1.0手的量，不允许我们分割。

例2（位置颠倒）。

我们有一个0.1手的多头头寸。我向服务器发送了0.2手的卖出订单。服务器是否接受这个命令？(又没有达到最低地段要求）。

这不是对零头寸的完全清算，所以申请将被拒绝。

例3（增加仓位量）。
我有一个0.1手的多头头寸。我向服务器发送了0.1手的买入订单。 服务器上有这样的订单实例吗？

当然不是。

请按字面意思阅读规则，不要试图编造自己的条件。该规则很简单，"当一个头寸被清算为零时，数量限制规则可能不适用"。这条规则已被多次提出。

你还应该考虑到，任何经纪人或任何交易所网关可以使用他们自己的、更严格的数量控制规则。

[[删除]]

我明白了，谢谢你的澄清。

[Саша]

IlyaBukalov:

突出显示开/闭括号的最大行数是128行。引入这一限制是因为突出显示不适合在一个屏幕上显示的开括号和闭括号是没有意义的。此外，引入这一限制后，MetaEditor的性能有了很大的提高。

当括号在128个字符串之后没有被高亮显示时，是非常不方便的，你经常要滚动两到三个屏幕 才能找到括号被关闭的地方。

[Andrey Khatimlianskii]

voix_kas:

这不是一个关键问题，但仍然是。字符串串联。文档描述了两个函数StringAdd 和StringConcatenate。

...

结果。

2011.06.26 19:10:55 test (EURUSD,H1)№12012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 milliseconds, i = 10000000

但事实证明，普通加法更快。

这个例子是不正确的。

第一个方法应该有 "result =result + string1 + string2 + string3;"

我也会为所有3个测试做出不同的结果，否则它们不会在同等条件下启动（一些内存已经被分配）。

甚至更好的是--把测试放到不同的脚本中，并按顺序运行它们。

我是这样想的。

1. 长度=10`000

2011.06.27 02:43:07 sStingTest (EURUSD,M1) №12542 milliseconds, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #20 milliseconds, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #30 milliseconds, i = 10000

2. 长度=100`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #247 milliseconds, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #315 milliseconds, i = 1000000

完成#1 - 没有等待

3. 长度=1`000`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #2780 milliseconds, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3187 milliseconds, i = 1000000

1号的结束并没有发生。

4. 长度=10`000`000

2011.06.27 02:48:14 sStingTest (EURUSD,M1) #31903 milliseconds, i = 10000000

MemoryException: 602492946 bytes not available "错误在第二次测试时开始出现。

结论：StringConcatenate是最快的。

顺便说一下，StringAdd 函数也 有不太正确的比较例子。

我测试它的代码在拖车里。