量化交易软件：作为创建自动化交易系统新方法的自动机编程

简介

对于利用 赫兹量化语言 开发 EA 的交易者而言，这是一个全新的主题。尝试在 MetaQuotes 网站上执行相关搜索时，我就意识到了这一点。有关该主题，还是一片空白。

每一位交易者都会创建属于自己的 EA 交易，且需要一套严谨的方法，来处理与编程及非常复杂的程序逻辑相关的各种问题。一天结束时，该程序应该会像任何标准与不可抗力情况下的发条装置一样自行运行。

但是，怎样才能实现兼容并蓄、无所不包呢？这个太困难了，正因如此，自动化控制系统才要求所有控制系统都要妥善编程，而且也只有利用自动机编程的相应编程技术，才能达到最佳效果。近些年来，与软件质量设置高要求的嵌入与实时系统编程技术的发展相关的领域，得到了极大的关注。

1991 年，俄罗斯作者 A.A. Shalyto（讲师、教授、工程理学博士、SPbSU ITMO 学院“编程”技术部主管）开发出了一个名为“自动机编程”的编程技术。见识一下简单的自动机编程或 SWITCH 技术，我觉得读者可能会感兴趣。它允许利用 MetaQuotes 语言，让 MTS 开发方便到无以复加的程度。而且，它会很好地融入到复杂决策制定体系当中。

​

编辑

添加图片注释，不超过 140 字（可选）

1. 彻底地研究问题

所有问题提出者及软件开发者长久以来魂牵梦萦的一个梦想，必然是拥有一套针对问题（算法）的有计划的解决方案，以及与其完全一致的该算法的实施。但事情的发展，往往不像提出者和开发者所想的那样。各种算法都倾向于忽略对开发者实施而言很重要的内容，而程序文本本身与算法又没有多少相似之处。

由此，存在两种算法 - 一种是书面的（用于记录和记载设计解决方案），通常会表示某种特定的设计成果，而不是获取某给定成果中采用的方法；另一种则在开发者的心中（但亦以文本方式保存）。

程序文本的最终版本之后，通常还会尝试修改文档编制，许多事情由此再一次被忽略。这种情况下，程序逻辑很可能与算法逻辑有所区别，因此显出缺乏一致性。之所以说是“很可能”，因为没人会检查某人的程序文本。

如果程序很大，那么，只靠文本来检查它是否与算法一致是不可能的。实施的准确度，可以利用一个名为“testing”的流程进行检验。基本上，它会检查开发者如何把握算法（付诸书面）、在头脑中将其转换成另一种算法并作为一个程序输出。最终，开发者是与逻辑相关宝贵信息以及实施变成完全不相干之前编撰的相关内容的唯一持有人。

就算开发者会生病（或... 辞职），也不是这样。重点在于，基本程序逻辑会根据每一位开发者的智力和对于编程语言的知识掌握而各不相同。任何情况下，开发者都会引入和使用大量其认为合适的中间变量。而且，如果程序很大且逻辑上很复杂，就需要一位更资深的专家来查找错误缺陷（我在这里所指，并非操作系统缺陷或语言函数的不正确使用，而是逻辑的不当实施），并通过程序文本本身解决它。

退一步讲，开发者中的大多数也都不愿意在编程之前先写下算法（甚至连在纸上大概画画都不愿意），而这很可能是因为某些事情他们仍要边做边想。确实，为什么要把时间浪费在绘制一些矩形、菱形和箭头上呢？最好是立即开始编程，然后再于文档编制中布置一个在某种程度上类似或非常通用的算法。

每个人都已经习惯于此了 - 开发者这么做是因为这种方式更简单；而问题提出者则不一定具备所要求程度的编程技能，而且即使是有，他们也根本不能对开发者想出来的内容进行及时的更改。方便的编程环境亦有助于指定开发顺序的有效性。用于调试的高级工具以及变量的监测值，则让我们有希望检测到逻辑中的任何错误。

随着时间的流逝和项目最后期限的逼近，开发者会坐下来为某个给定的逻辑问题草拟一份“餐巾纸”解决方案，顺便说一下，仍需要实施，更不用说后面跟随大量相同（混乱）情景的测试期间被忽视的错误了。当前的情况就是这样。有没有什么解决方案，或者至少能够改善？感觉像是，在从一种按标准方式规定的算法迁移到该程序代码的过程中，丢掉了某些重要的东西。

2. 程序的逻辑部分

“自动机编程”的作者提出了有关某程序理想逻辑部分的下述理念。程序的整体逻辑基于切换。简言之，任何控制算法（自动机）均可如下实施（这里并未过多考虑注释的意义，只是大概看一下结构）。

switch(int STATUS ) // Мulti-valued global state variable of the automaton. { case 0: // start // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. 0 // Calling nested automata. // Execution of output functions in the state. break ; case 1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; ********* ********* ********* case N-1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; case N: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; }

3. 作者 A.A. Shalyto 所阐释的自动机编程

不论开发技术如何，任何程序都拥有由其任何特定时间点的所有数据值确定的状态。大型应用程序中，可能会有数百乃至成千上万的变量和多个控制流。而这些变量的一个完整的集，则会描述出该应用程序在任何特定时间点的状态。

程序状态可以作为全部控制变量中的一系列（参与所有迁移情况的）精选值以一种更简单的方式进行处理。如果更改某控制变量的值，则意味着程序状态的变化，而程序状态的数量则由程序运行期间出现的控制变量值的最大可能组合数量确定。假设某程序中仅使用二进制控制变量（标志）。那么这种情况下，包含 n 个二进制控制变量的程序的状态数量范围就会在 n 到 2n 之间。

它可能是由开发者提供的，用于应对控制变量值的所有组合（本例中为 2n 种组合）。但是，更有可能的情况是，控制变量值的某些组合（最多为 2n-n）最终是未指定。那么，只要出现了意外的输入动作组合，此程序即可迁移到一个未指定状态。

下述事件中，它与某交易者 EA 的不活动有同等效果：

• 缺口，

• 预付款的损失，

• 落入一种负余额境地，且随之需要追加预付款，

• 未能很好地获利直到趋零，并进一步呈红色，

• 买入持仓与卖出持仓的不正确建仓与平仓，

• 其它明显的负面情况。

这种状态被称为 "unvisualized"（非可视化）。复杂性造成了枚举的困难，更难以接受的是，此程序的所有可能状态都会导致其不可靠……结构的复杂性，是构成安全陷阱的各种非可视化状态的源头。从内存保护故障到拓展程序新功能并生成各种性质的副作用，处于未指定状态下的程序行为各有不同。

大量的 PC 用户，很可能还有所有的软件开发者，都常常会碰到使用或开发过程中，某程序进入一种未指定状态的情况。

要消除程序中的这种未指定状态的可能性，早在设计阶段就要显式指定所有需要的状态，而且用于区分它们的只能是一个多值的控制变量。之后，有必要识别各状态之间的所有可能迁移，并以其不能“误入歧途”为原则开发一个程序。

要在程序行为的开发过程中达到严格要求，需要三个分量：

• 允许明确识别程序状态以及各状态之间可能迁移的数学模型；

• 此模型的图形化标记；

• 此标记中表示算法实施的通用方法。

建议将基于 "state" 概念的一个有限自动机作为一个数学模型使用。自动机编程会为设计、实施、调试及归档之类的软件开发阶段提供支持。

其中的术语 'event'近些年来在编程中越来越常见，提议的方法基于 'state' 概念。将其与术语 'input action' （既可作为一个输入变量，亦可作为一个事件）结合后，即可引入术语 'automaton without output'。继后者之后，又会进一步引入术语 'output action' 以及（决定性有限） automaton 概念。基于此理念的编程领域由此被称为自动机编程，而各个开发过程则被称为自动机程序设计。

应用时，指定的方法在这方面很特殊，自动机由迁移图表示。为在各节点间进行区分，又引入 'state assignment' 术语。如果选择一个 'multi-valued state assignment' （多值状态分配），与选定变量可取值数量一致的那些状态，可以通过只采用一个变量的方式进行区分。有这一事实的存在，术语 'program observability' 才得以引入编程。

遵照提议方法的编程，会通过 'states' 而非 'variables' （标志）来执行，从而有助于更好地理解并指定问题及其分量。这种情况下的调试，则是依据自动机的记录完成的。

由于上述方案提议从迁移图转至带有正式且同构方法的程序代码，所以如果采用的是高级编程语言，按此作法来应用切换结构似乎更为合理。正因如此，才决定在引用自动机编程范式时采用术语 'SWITCH-technology'。

4. 显式状态编程

自动机方案的应用，已被进一步延伸到亦被称为 'reactive' （反应性）的事件驱动系统。反应系统会利用相关讯息，按照环境（相同的类中可以纳入一个 EA）设置的速度与环境进行交互。

利用自动机开发事件驱动系统得以实现，采用的是过程性方法，而显式状态编程亦由此得名。在此方法中，输出动作会被分配到迁移图（使用的是混合自动机 - Moore 与 Mealy 自动机）的弧、循环或节点。此法允许获取（作为相关输入动作反应的）动作序列的一种紧凑表示。

设定系统给定类的提议方案的逻辑更为集中化，因为它由事件事件处理程序中被移除，并生成一个由处理程序调用的互联自动机系统。该系统中自动机之间的交互，则可以通过状态数量的嵌套、调用及交换来实现。

该互联自动机系统会构成一个独立于系统的程序部分，而依赖于系统的部分则通过输入与输出动作函数、处理程序等构成。

给定方案还有一项关键特征，那就是应用时，自动机是以三位一体的方式使用：

• 用于规格；

• 用于实施（它们仍在程序代码中）；

• 用于依据自动机的日志记录（上文已指定）。

后者允许控制自动机系统操作的准确度。日志记录基于开发的程序自动执行，而且可用于带有复杂程序逻辑的大规模问题。这种情况下，每一个日志都可被视为一个相关脚本。

日志允许监视运行中的程序，并阐明自动机并非“图片”，而是真实活动实体的事实 。建议自动机方法不仅用于创建控制系统，还可以用于控制对象的建模。