文章 "并行粒子群优化"

[MetaQuotes]

新文章 并行粒子群优化已发布：

本文介绍了一种基于粒子群算法的快速优化方法。本文还介绍了MQL中的方法实现，它既可以在EA交易内部的单线程模式下使用，也可以作为在本地测试人员代理上运行的附加组件在并行多线程模式下使用。

从算法的角度来看，PSO方法相对简单。其主要思想是在EA交易的输入参数空间中生成一组虚拟“粒子”。然后，粒子移动并根据EA在空间中相应点的交易度量改变其速度。该过程重复多次，直到性能停止改善。该算法的伪代码如下：

粒子群优化伪码

根据这个代码，每个粒子都有一个当前的位置、速度和过去“最佳”点的记忆。这里，“最佳”点是指达到该粒子目标函数最高值的点（一组EA输入参数）。让我们在类里面描述一下。

  class Particle
  {
    public:
      double position[];    // current point
      double best[];        // best point known to the particle
      double velocity[];    // current speed
      
      double positionValue; // EA performance in current point
      double bestValue;     // EA performance in the best point
      int    group;
      
      Particle(const int params)
      {
        ArrayResize(position, params);
        ArrayResize(best, params);
        ArrayResize(velocity, params);
        bestValue = -DBL_MAX;
        group = -1;
      }
  };

所有数组的大小都等于优化空间的维数，因此它等于正在优化的专家顾问参数的数目（传递给构造函数）。默认情况下，目标函数值越大，优化效果越好。因此，用最小可能的 -DBL_MAX 数值来初始化 bestValue 字段。其中一个交易指标通常被用来作为评估EA的标准，如利润、盈利能力、夏普比率等。如果通过较低值被认为更好的参数，例如回撤，来执行优化，则可以进行适当的转换以最大化相反的值。

数组和变量是公有的，以简化访问和它们的重新计算代码。严格遵守OOP原则需要使用“private”修饰符隐藏它们，并描述读取和修改方法。

作者：Stanislav Korotky

[fxsaber]

Таким образом, мы убедились, что алгоритм PSO стал доступен в своей параллельной модификации в тестере в режиме оптимизации.

这句话读完了。非常酷！通过文件将并行计算 带入工作状态，这是一项巨大的原创性工作。

[Andrey Dik]

参数库的唯一性检查和存储是否合理？是否对算法的速度劣化进行过测量？

考虑到优化过程中通常会使用巨大的搜索空间，而重复变体的概率极小，在搜索空间较小的情况下，进行完整搜索更为合理。

ZЫ 感谢作者提供了思考的基础。

ZZY 我在重读这篇文章时，还不太明白如何解决在不停机的情况下，在殖民地（或种群）规模固定的情况下 "软 "加载代理的问题。

[fxsaber]

这篇文章展示了 MT5 方面的一些尚未解决的问题。例如，在没有 DLL 的情况下获取 OnTesterInit 中的非优化参数值。还有同样的委托。

如果能在源代码中添加通过 DLL 读取所有测试器参数的功能（通过宏），那就更好了。有现成的解决方案。

另一个愿望是从 PSO-passes 生成选项文件。

有必要在性能和质量方面对这一解决方案和标准 GA 进行实际比较。这对任何非同步器 TC 来说都不是难事（根据文章中的资料来源，因为这是一种通用风格）。

这篇文章很棒！但不适合初学者。

[Andrey Dik]

读完了。

对于替换标准优化器的任务来说，代码太多了，包含的内容太多了，谁会看得懂呢？- 不幸的是，对于绝大多数读者来说，这篇文章仍然无法理解。

如何才能以最小的代价将任何智能交易系统和 PSO 库结合起来？

理想情况下，优化算法应该是一个完全独立的实体，这样您就不必在每次编写新的智能交易系统（您计划优化的任何算法）时都要进入优化算法。

此外，在大多数实际情况下，什么样的算法设置是可以接受的？- 作者没有给出答案。而且，如果好奇心强的读者想使用相同的算法优化 算法参数，也不可能马上做到，因为代码不是孤立的。

请不要认为我是在发牢骚，但没有一个现成可用的工具不需要为特定任务编写代码。

[Stanislav Korotky]

Andrey Dik:

完成了

对于取代标准优化器的任务来说，代码太多了，包含的内容太多了，谁会看得懂呢？- 不幸的是，对于绝大多数读者来说，这篇文章仍然无法理解。

你如何能以最小的代价将任何智能交易系统和 PSO 库拧在一起？

理想情况下，优化算法应该是一个完全独立的实体，这样您就不必在每次需要编写新的智能交易系统（任何需要优化的算法）时都去研究它。

此外，在大多数实际情况下，什么样的算法设置是可以接受的？- 作者没有给出答案。而且，如果好奇心强的读者想用同一种算法优化算法参数，也不可能直接做到，因为代码不是孤立的。

请不要认为这是在发牢骚，但没有一个现成可用的工具不需要为特定任务编写代码。

当然，我们也不能一味拥抱巨大。开源工具的第二次迭代已经推出（第一个非并行化的工具已于早些时候在博客上发布）。从这个意义上说，它已经准备就绪，因为他们已经为你设计好了代码的位置和工作方式。我同意现在还没有盒装产品。但它会在市场上出售。这里展示的是一个带有现成说明的 DIY 工具包。

至于附加功能--添加这些功能并不是因为生活美好，而是因为没有类似的内部方法来完成相同（和所需）的一切。很好的一点是，所有这些例行工作都已经以 includniks 的形式准备就绪，只需连接即可（为此非常感谢 fxsaber-u）。在一个算法交易网站上抱怨避免重复工作的主要方法是很奇怪的。如果没有这些包含器，我们就不得不从头开始整个项目。有 includniks 总比有 batniks 好。一般来说，我们不依赖第三方程序和 DLL。除了内置的优化方法外，没有（任何）其他方法可以通过小代码来实现。

至于 PSO 参数的调整，这对任何优化方法来说都是一个未决问题。特别是，内置 GA 有一些用户无法更改的硬连接设置，这就是为什么很多人抱怨这一点，他们不得不向你订购基于 GA 的定制解决方案。事实证明，没有设置是不好的，有设置也是不好的，因为你把设置给了我们，而我们现在却不知道该如何处理。而如何使用它们就是：针对每项具体任务进行研究。要求为某个未知的黑盒子，也就是某人的专家，提供现成的设置，就好比要求为这个专家提供理想的参数（不需要优化）。那我们为什么还需要优化呢？因为事情并不那么简单--既不是寻找专家的参数，也不是寻找特定优化算法的元参数。你所要求的，就好比要求为尚未有人见过的数据提供现成的神经网络配置。在大多数专家==实际案例中，并不存在最优设置。

作为一个起点，我们可以将文章中与遗传算法并行的方法作为参考：如果用户已经运行了 1000 次遗传算法，那么让他将组数设置为 1000，如果遗传算法有 100 代，那么让它成为 100 个 PSO 循环，如果种群中有 100 个个体，那么让群的规模也是 100。

[Andrey Dik]

Stanislav Korotky:

至于 includnics - 添加它们并不是因为生活美好，而是因为没有类似的标准方法来做所有相同（且必要）的事情。很好的一点是，所有这些例行工作都以 includniks 的形式现成提供，只需连接即可（感谢 fxsaber 提供）。在一个算法交易网站上抱怨避免重复工作的主要方法是很奇怪的。如果没有这些包含器，我们就不得不从头开始整个项目。有 includniks 总比有 batniks 好。一般来说，我们不依赖第三方程序和 DLL。而且，除了内置优化方法外，没有（任何）替代方法可以通过小代码来实现。

以虚拟交易函数 的形式重复标准测试器的功能是没有意义的（至少我看不出有什么意义，这项工作已经由 MQ 高薪聘请的聪明人为我们完成了），但做一个补充、功能扩展--是的。

粗体 - 也许吧。

至于 PSO 参数的调整，这对任何优化方法来说都是一个未决问题。特别是内置的 GA 有一些用户无法更改的硬性设置，这就是为什么很多人抱怨这一点，他们不得不向您订购基于 GA 的定制解决方案。事实证明，没有设置是不好的，有设置也是不好的，因为你把设置给了我们，而我们现在却不知道该如何处理。而如何使用它们就是：针对每项具体任务进行研究。要求为某个未知的黑盒子，也就是某人的专家，提供现成的设置，就好比要求为这个专家提供理想的参数（不需要优化）。那我们为什么还需要优化呢？因为事情并不那么简单--既不是寻找专家的参数，也不是寻找特定优化算法的元参数。你所要求的，就好比要求为尚未有人见过的数据提供现成的神经网络配置。在大多数专家==实际案例中，并不存在最优设置。

作为一个起点，我们可以从文章中与遗传算法的平行关系入手：如果用户已经运行了 1000 次遗传算法，那么就让他把组数设为 1000，如果遗传算法有 100 代--那么就让它是 100 个 PSO 循环，如果种群中有 100 个个体，那么就让蜂群规模也是 100。

准备就绪的神经网络和优化算法是不一样的，准备就绪的神经网络需要在特定数据上进行训练，并依赖于数据的纯度、完整性和相关性，但优化算法不应该以任何方式依赖于这些因素，它不应该关心是训练神经网络（优化）还是在一组测试问题上找到自身的最优参数。

但是！无论如何，我对这篇文章的评论纯粹是实用性的，而不是原则性的。关于优化问题的任何观点都有存在的权利。你是这么看的，而我的看法有些不同，这很好。

在当今世界，没有人需要 "自己动手 "的设计师，每个人都需要现成的解决方案，买奔驰和其他奥迪车不是为了完成，而是为了享受.. ....或者至少应该提出一种低成本的方式，将解决方案与客户的现有项目拧成一股绳。

;)

[Igor Makanu]

有趣 的文章

我不喜欢将虚拟交易与测试器联系起来的做法、

也许它能达到预期效果，但我认为，优化的实现应该完全借助虚拟交易（ Virtual.mqh） --这样就能实现在线自动优化、

或者利用终端策略测试器（OnTesterInit()）来实现。- 我们将获得测试仪的替代 GA，在当前实施中很难假设策略测试仪是如何工作的。

感谢您提供的有趣资料和软件实现，它可能会很有用。

[Stanislav Korotky]

我将按顺序回答。

记住计算组合的哈希值是可选项--如果需要，可以从源代码中排除。与交易本身的计算速度相比，这种检查的存在应该不会大大降低交易过程的速度。

完整的参数枚举只对非常小的空间有意义，但在它们和数百万个组合之间，还有一整层用例。例如，您需要对 10000 种组合进行优化，全面搜索需要 1 个小时，但您希望在几分钟内就能看到粗略的估计结果。在这种情况下，您显然需要一种快速的优化方法，而重复的组合是很有可能出现的。通过检测它们，我们可以加快处理速度。

代理的加载由测试人员负责。贸易通行证平均分配（数量相等，复杂性因随机化而平均）。

我想添加选项文件，但无法一次全部完成。如果你把所有选项都拧进去，结果将永无天日。

我不想使用 DLL 和外部程序，可以说，这是设计上的问题。

使用虚拟交易函数 非常有意义--它们比内置函数 快得多。这是第一点。其次，它们允许您在一次循环中（在 PSO 组内）多次更改参数。如果不是这样，每个单独的通道都必须与编组同步（编组已成为与程序相关的外部实体），而这仍然可以通过外部程序或共享文件来实现。此外，还将出现新的超级制动器。但第三点，也是 最后一点，也是最重要的一点： 在没有虚拟化的情况下使用常规测试器通道时，不可能将自己的优化算法植入 MQL。试着想想你会怎么做。这只有在外部程序和/或网络的帮助下才能实现。fxsaber 甚至有合适的 "自动化程序"，但这意味着对运行过程和组合结果的外部控制。这简直是煞费苦心，而且使用起来完全不方便。处理这些外部控制器需要更多的技巧。

至于关于用小代码实现标准优化器替代的说法，我不敢苟同。据我所知，替代工程也不小，需要对专家代码进行调整。如果有代码量小、插入 EA 非常简单的独立优化算法的具体演示，请与公众分享;-)。

关于优化算法的漠不关心，好像它不需要调整就能处理任何任务--我不同意。那将是一种魔法，一种 "银弹"。

我看不出优化算法和 NS 算法有什么本质区别。两者都有元参数。

没错--"没有做任何工作 来研究算法的搜索能力"，因为你不可能覆盖很多领域--已经有很多工作要做了。出版物的目的是将其公开给那些想要进行研究并分享研究成果的人。

网上有自动优化（已在博客中发表），但它只在一个线程中，文章的重点是并行化算法。将测试仪用作作业迭代器，并将它们分配给代理进行分组虚拟计数 -- 这是整个项目最大的诀窍。协同作用。

[Stanislav Korotky]

我附上了稍作修改的头文件和一个测试智能顾问的示例。设置类、辅助函数和模板事件处理程序包含在 ParticleSwarmEmbed.mqh 文件中。假定用户对其默认实现感到满意。这样，Expert Advisor ExprBotPSOEmbed.mq5 的代码就大大简化了。只需在 PPSO_EventHandlers 类中描述交易计算和抛出处理程序即可。此外，PSO 动态设置系数（惯性等）以及索引文件的禁用也被放入输入变量中。

[Stanislav Korotky]

表达式解析器类中的小错误修复。该错误不会影响文章中示例的工作，但可能会影响其他示例。