文章 "种群优化算法：模拟退火（SA）。第 1 部分" - 页 2

[Andrey Dik]

Aleksey Nikolayev #:
没错。

无论是编码还是进一步的实际使用，这都是一项极为不便的技术。例如，内部优化器不使用它就证实了这一点。

当需要进行多次优化（次数不确定，每次优化的参数也可能不确定）时，这种方法就很难应用。例如，这可能是集合 MO 模型。

这里可以说的是......OpenCL 并不可怕，也不方便，它的代码在语法上与 MQL5 没有区别（除非您使用 MQL5 特有的函数）。您不仅可以并行化单独的逻辑代码段，还可以并行化 Expert Advisor 的整个逻辑，例如，在 OpenCL 中以代理上的标准优化器的方式组织历史运行。因此，有可能在 "专家顾问 "的在线模式下组织优化/培训。

MetaQuotes 提供了并行化功能，但如果本地语言功能可用，那就太好了。我认为，对于开发人员来说，实现函数三元组（等待用户更快）比代码段自动并行更容易。作为开发人员的一个愿望，我希望它能被听到。

[Aleksey Nikolayev]

Andrey Dik #:
这里可以说的是...OpenCL 并不可怕，也不方便，其中的代码在语法上与 MQL5 没有区别（除非您使用 MQL5 特有的函数）。您不仅可以并行化单独的逻辑代码段，还可以并行化 Expert Advisor 的整个逻辑，例如，以代理上标准优化器的方式组织历史运行。这就是在 Expert Advisor 的在线模式下组织优化/培训的方式。

问题并不在于编码本身，尽管可能会因为缺乏手册而出现问题。据我所知，将程序移植到调试时使用的 GPU 之外的 GPU 时也会遇到问题。同样，我也不确定当 MT5 通过 wyne 在 linux 中运行时，这种情况是否会出现。找到的问题解决方案总是会因 MT 的意外更新等而中断，
。

Andrey Dik#:
MetaQuotes 提供了并行化功能，但如果有本地语言功能，那就太好了。我认为，对于开发人员来说，实现函数三元组（等待用户更快）比自动并行化代码片段更容易。作为开发人员的一个愿望，我希望它能被听到。

在我看来，可能性太小了。

[Aleksey Nikolayev]

Andrey Dik #:

关于群体退火出现了一个问题。让群体中的每个解选择其退火参数（在合理范围内随机选择）是否合理？这能否 a) 提高收敛性，b) 成为选择最优元参数的某种类似方法？

[Andrey Dik]

Aleksey Nikolayev #:
问题并不在于编码本身，尽管它们很可能会因为缺乏手册而出现问题。据我所知，将程序移植到调试时使用的 GPU 之外的 GPU 时会出现问题。同样，我也不确定当 MT5 通过 wyne 在 linux 中运行时，这种情况是否会出现。已找到的问题解决方案总是会因 MT 的意外更新等原因而失效。

OpenCL 正是作为在多核设备上组织并行计算的通用方法而开发的（不管是 GPU 还是 CPU）。OpenCL 程序在不同设备上出现问题的概率并不比普通 Windows 应用程序在不同硬件的计算机上出现问题的概率高（甚至可能更低）。

我不知道 vyne 的情况如何，它一直存在问题，这取决于 Windows 环境虚拟化的具体情况和质量。

[Andrey Dik]

Aleksey Nikolayev #:

关于群体退火，出现了一个问题。让群体中的每个解选择其退火参数（在合理范围内随机选择）是否合理？这能否 a) 提高收敛性，b) 成为选择最优元参数的某种类似方法？

问得好。在测试算法和选择算法的外部参数时，我会从一组测试函数的整体总体性能出发，尽管每个测试函数的最佳参数可能不同（通常也不同）。此外，对于不同的问题维度，不同的外部参数也可能是最佳参数。因此，可以

a) 可以提高对不同类型问题的收敛精度，降低卡住的概率。

b) 是

唯一的问题是，这种技术在提高收敛精度的同时，可能会降低一点收敛速度（或者降低很多，你应该看看）。

[Aleksey Nikolayev]

Andrey Dik #:

问得好。在测试算法和选择算法的外部参数时，我会从一组测试函数的整体总体性能出发，尽管每个函数的最佳参数可能不同（通常也不同）。此外，对于不同的问题维度，不同的外部参数也可能是最佳参数。因此，是的：

(a) 可以提高不同类型问题的收敛精度，降低卡住的概率。

b) 是

唯一的问题是，这种技术在提高收敛精度的同时，可能会稍微降低收敛速度（或者降低很多，你需要看一下）。

感谢您的翔实答复。如果进行了实际实验并取得了有趣的结果，我会在这里写出来。现在，我只是出于好奇，想了解一下您关于优化的系列文章。