组织订单周期 - 页 4

新评论
 
fxsaber:

不会的，因为它不强壮。


首先，TS是为测试者写的，那里的交易条件很理想。如果一切顺利，那么他们就会尝试以这样一种方式来编写实时版本，使其尽可能地接近他们在测试器中看到的情况。任何其他撰写TS的方法都是命题作文，而不是想法的算法化。

因此，这里有一个基本问题，什么是与测试员最接近的战斗情况？我表达了我的意见（并举了一个例子），我听到了你的意见。

我面临的任务是将专家顾问的交易逻辑从策略测试器（MT4）中的滴答测试转化为真实账户上的工作。

我的理由是。

在测试器中，专家顾问不仅在理想的交易条件下工作，而且实际上是在另一种模式下工作--实时，即它有时间计算TS，并发送一个订单，并在一个点上得到它的答案，但在实际交易中却不是这样。似乎我们有某种程度上的两个不同的机器人-- 一个是实时的，一个是无时间的。如果我们发送/修改一个订单（即使是一个！）到一个真实的账户= ping +执行时间，等等。= 最多 100-500 毫秒，在这段时间内蜱虫走了，它们需要被计算 - 我们站着，等待...然后我们随机进入流量（相对于我们的滴答平均数，这段时间的价格走到哪里了我们不 知道。+ 我们一定是错过了一些最快的、通常也是最重要的时间点）。因此，结果是，我们在测试器中执行的策略可能什么都没有留下。

因此，经过思考，我得出以下结论。

  1. 在 战斗模式下， 专家顾问的交易逻辑被禁用，事实上，它作为一个追随者工作。
  2. 交易系统被移到指标中，它产生开盘和收盘指令，它不等待专家执行这些指令，而只是在理想条件下执行它所拥有的TS，几乎就像在测试器中一样。据我所知，该指标不能跳过刻度线，虽然我怀疑这在技术上是否可行--但至少它跳过的刻度线必须比专家顾问少，因为专家顾问最初在其文档中描述了这种可能性。+ 即使是以分离为代价的TC计算错误也应该更少，因为没有中断与TC逻辑有关的各种次级操作。
 
zenz:

因此，经过思考，我得出以下结论。

  1. 在 战斗模式下，专家顾问的交易逻辑被禁用，事实上，它作为一台复制机工作。
  2. 交易系统被移到指标中，它产生开盘和收盘指令，而且它不等待专家顾问执行这些指令，而只是在理想条件下执行TS，几乎就像在测试器中一样。据我所知，该指标不能跳过刻度线，虽然我怀疑这在技术上是否可行--但至少它跳过的刻度线必须比专家顾问少，因为专家顾问最初在其文档中描述了这种可能性。+ 甚至由于分离的错误在TC计算中应该更少，因为没有中断各种次要的TC操作的逻辑。

是的，我使用同样的方法--一种内部的理想测试器，它有自己的未结订单和一个试图实现这些虚拟订单的复制器。这个计划非常容易地绕过了很多严重的问题。


在MT5中，这更容易，因为我们可以在那里申请tick历史。而且你可以为几个符号提出要求。

 
Stanislav Korotky:

这不是时间问题，而是逻辑问题（关于时间--那是另一个话题;-) ）。你的逻辑（也是我的逻辑，因为我同意所有的东西，包括汽车的比喻）是 "一气呵成 "地进行环境分析，而不是零敲碎打。对任何副作用的处理都要推迟到下一次运行，因为这些影响将被建立在新的交易环境中。

好吧，如果没有时间校正，那么两个逻辑（我的和fxsaber的）将是相同的 - 所有订单将在每个tick 上被处理，即使有几个错误。

我们的目标正是以非即时执行的方式将现实与测试中获得的理想模型相近。

 
fxsaber:

是的，我使用同样的方法--一种内部的理想测试器，它的未结订单和一个试图实现这些虚拟订单的复制器。

如果你用你的方法实现（在一个循环中，停留在第一个订单上，直到它成功地与现实同步），你可能会遇到同样的问题，即其余的订单会从视野中消失（或只是在后来被处理）。但这是关于同样的、据说已经完成的主题）。

 
Andrey Khatimlianskii:

如果你用你的方法实现（在一个循环中，停留在第一个订单上，直到它成功地与现实同步），你可能会遇到同样的问题，即其余的订单会从视野中消失（或只是在后来被处理）。但这是关于同一个问题，据说已经被解决了）。

这就是我们的交易方式!

 
fxsaber:

我们正在等待一个OOP的例子。而我仍然认为它是以循环的形式出现的同样的主干。逻辑不会改变，因为首先要确定什么是必须改变的，然后再为我们已经做出的决定。

我不会专门为这项任务写一个例子。但你可以在我的博客 中看到该方法的一个简化概念。在那里，队列没有被深入分析，而只是检查是否空虚。愿意的人可以改进它。

如果我们所说的逻辑是指 "由于价格变化而修改一堆订单 "的任务，那么只有一个任务。问题是什么更重要：是修改所有的 订单还是修改它们以适应最新的价格？根据你的喜好，逻辑会有所不同。一个简单的循环可以保证所有的 订单都被修改，我赞成这个方案。正如已经说过的，OOP提供了一个明确的任务划分责任块，基于这种分解，"所有订单 "比 "价格相关性 "更重要。这一点即使从价格一直在变化，而订单只是偶尔存在的事实中也可以看出。他们更重要。

 
Stanislav Korotky:

PLO在将任务划分为责任区方面提供了明确性，基于这种 分解，"所有订单 "比 "价格相关性 "更为重要

基于这种分解，只需进行划分。在这个PLO中，"价格相关性 "是通过在队列中设定一个位置来实现的。
 
fxsaber:
基于这种分解，只有分离才会出现。这个OOP下的 "价格相关性 "是通过在队列中设定一个位置来实现的。

这已经是一个有点 "哲学 "的问题了。处理是按订单队列进行的，而不是按备选方案中建议的tick flow进行的。无论如何，我将退出这次讨论。所有的论点都已经提出来了。

 
Stanislav Korotky:

无论如何，我将退出这次讨论。所有的论点都已经提出来了。

已经有了以这种方式结束的倾向。

 
fxsaber:

下面我们将谈到一个不仅涉及MT4，而且涉及MT5与其他平台的话题。但逻辑将用MQL4编写，以方便感知，所以在这个分支中。

大多数情况下，订单修改/删除的主干（任何订单的主要内容）归结为以下逻辑

现在，这种做法很罕见，但更正确了

在发送交易指令 后，交易环境会发生变化，因此建议在交易服务器响应后立即从头执行TS的整个交易逻辑。

循环是最危险的编程技巧之一。它导致奇怪的、很少发生的错误，这些错误几乎无法分析。

与其说是循环，不如说是尽量快速完成用户流程。如果你想把握住你的脉搏--分析MT5的OnTradeTransaction。MT4一般不适合这种循环，因为正如他们所说，简单比盗窃更糟糕。

1234567891011...15
新评论