应对交易环境时的典型错误和如何处理这些错误 - 页 6

新评论
 
Комбинатор:
我们已经讨论过 了。它不会是普遍的，因为一个人需要一种东西，另一个人需要另一种东西。
我呼吁回归现实。而如果存在市场订单形式的不确定性，那么要么等待其结果并输出已经发生的情况，要么让程序决定如何处理。但肯定不是为了随机返回一个数量。
 
Artyom Trishkin:
我呼吁回归现实。而如果存在市场订单形式的不确定性，那么你要么等待其结果并返回已经发生的事情，要么让程序决定如何处理它。但肯定不是为了退货而退货的数量。

这不是一个交换条件，这就是事实。有两个职位 完全可以改变，一个被冻结（没有改变）。总共有三个职位。这与你作为参考的MT4逻辑非常吻合。

 
Artyom Trishkin:

如果MC做了一个正常的同步操作，就根本不会有这样的问题。

此外，fxsaber已经解释了他为什么这样做，以及为什么他对我的逻辑不满意。

 

关于交易、自动交易系统和交易策略测试的论坛

在交易环境中工作时的典型错误以及如何解决这些错误

fxsaber, 2018.02.24 16:25

我甚至会告诉你这种被取消的市场订单是什么样子的

只是没有错误。

这个例子变成了更酷的例子。经纪人自己放置的TP被编码了!几乎是在重新定单关闭后的第一时间（我等待了115毫秒--显然，这是MT5的一个错误），经纪人设置了另一个TP，并被执行。订单的评论没有在截图中显示出来。绿色的是ORDER_REASON_TP。因此，拒绝订单甚至有一个ORDER_POSITION_ID。

 
Комбинатор:

如果MCs进行正常的同步操作，就根本不存在这样的问题。

这样的OrderSend可以由编码员自己编写。当我使用同步OrderSend时，这是我使用的解决方案。

应该理解的是，如果主持人自己写，可能会被超时。从逻辑上讲，管委会对发送到第三方系统的市场订单不负责任。

我很努力地尝试，但还是想不出2 + 1 != 3 在哪里是重要的。


ZZZ还有一个异步的变体。而在那里，很有可能会遇到市场订单。因此，即使MCs进行了 "正常的同步操作"，这样的位置 计数功能也是相关的。

 
fxsaber:

这个OrderSend可以由编码员自己编写。当我使用OrderSend的同步变体时，这是我使用的解决方案。

然而，应该理解的是，如果主持人自己写出这样的解决方案，可能会被超时。从逻辑上讲，管委会对发送到第三方系统的市场订单不负责任。

我很努力地尝试，但还是想不出2 + 1 != 3 在哪里是重要的。

不，不是的。在你的情况下。2 + 1 - 1 = 3
 
Artyom Trishkin:
不，不是这样的。在你的情况下。2 + 1 - 1 = 3

我意识到我们有不同的算术。也许不应该继续。但是，影响买多多停止发布带有错误的代码，这将是值得的。

 
fxsaber:

我意识到我们有不同的算术。也许不应该继续。但为了让QB停止发布有缺陷的代码，这可能是值得的。

而为了影响他们，他们需要理解我，并讨论修复这一缺陷的可能步骤。但你顽固地没有看到你建议的方法可能存在的缺陷。我可以做什么？劝说你倾听而不是珍惜你的方法？所以你没有在听。
 
fxsaber:

我很努力地尝试，但还是想不出2+1 !=3 哪里重要。

当策略意味着对未结头寸 的立即反应时。在这种情况下，重码可以打破逻辑。

在绝大多数情况下，任何核算（包括作为位置的订单和作为中间非工作状态的订单）都会带走问题。

fxsaber:

这样的OrderSend可以由编码员自己编写。

奇怪的逻辑，我也可以这样写终端。在MT4之后，它看起来像是把问题转移到了编码者的头上。还有很多事情。

 
Комбинатор:

当策略意味着对未结头寸 的立即反应时。在这种情况下，重定向可以打破逻辑。

恐怕这是歪理邪说。但我可能是错的，当然。如果能听一听其中的逻辑，那就很有意思了。

奇怪的逻辑，我也可以这样写终端。在mt4之后，它看起来像是把问题转移到了编码者的头上，很多事情都是如此。

我想这仍然是一个不知情或薄弱的文件问题。我想如果一切都在那里得到很好的解释，就会减少错误和这种对话。但这可能就是这个论坛的作用。因为很明显，在文件中不可能考虑到一切。

ZZY 我的现成解决方案的源代码被公布在公共领域。

12345678910
新评论