文章 "随机数生成器质量对优化算法效率的影响" - 页 4

 
Andrey Dik #:

是的,当然是修改和改进。因此,代码库将是一个很好的解决方案。

比 git 更好。你可以查看版本历史,轻松查看每个文件的所有改动,报告问题或对某一行代码发表评论,等等。

 

在我看来,要评估优化的有效性,最重要的是找到的参数在 OOS 样本(例如,k-fold 交叉验证)上的表现,而我还没有注意到这样一个主题--也许我在什么地方错过了。

通常情况下,问题不在于找到最细致的优化算法,而在于让系统尽可能地持续表现良好。我的感觉是,反向测试中的最优参数在正向测试中的寿命不够长,因此应该以其他方式来评估效率,例如,通过给出平均最高 FF 值的连续平滑参数集群的大小来评估。

顺便说一句,我在表格中没有看到任何速度比较。

 
Stanislav Korotky #:

而且,为了评估优化的效率,在 OOS 样本(例如,k-fold 交叉验证)上对找到的参数进行工作是最重要的,而我还没有注意到这样一个主题--也许我在什么地方错过了。

通常情况下,问题不在于找到最细致的优化算法,而在于让系统尽可能地持续表现良好。我感觉,回溯测试中的最优参数在正向测试中的寿命不够长,因此应该以其他方式来评估效率,例如,通过给出平均最高 FF 值的连续平滑参数集群的大小来评估。

顺便说一句,我在表格中没有看到任何速度比较。

您提到了交易系统的稳健性问题,这个问题与优化算法本身没有直接关系。

在这一系列文章中,优化算法本身作为一种工具被考虑并相互比较。

与实际任务中的 FF 计算相比,算法的代码执行速度可以忽略不计,因此进行测量并无特殊意义。

粗略地说,我们比较的只是铁锹,哪种铁锹切地更好,切到什么深度,这与铁锹的用途无关:挖洞种土豆还是种黄瓜,也不研究铁锹对蔬菜成熟速度的影响。


ZЫ.系统参数的优化和稳健性是两码事,但由于某种原因被错误地联系在一起。要确定稳健性参数,应使用其他方法(作为结果的后处理或与优化同时进行),如确定具有共同系统行为的参数群和其他方法。

 
Andrey Dik #:

您提到了交易系统的稳健性问题,这个问题与优化算法本身没有直接关系。

但您决定深入探讨 HSC 质量对优化的影响问题(即您偏离了与优化算法直接相关的内容)。这是值得称赞的。但在我看来,更重要的是找到的解决方案的稳定性,这可能是通过在 FF 空间中评估 "更好 "的不同方法来实现的。这与优化算法及其实际应用性直接相关。

 
Stanislav Korotky #:

1.您决定深入研究 DST 质量对优化的影响问题(即您偏离了与优化算法直接相关的内容)。这是值得称赞的。

2.但在我看来,更重要的是找到的解决方案的稳定性,这可能是通过在 FF 空间中估算 "更好 "的不同方法实现的。这直接关系到优化算法及其实际应用性。

1.HCS 质量的影响是一个合理的问题,因为迄今为止考虑的所有算法(除 Nelder-Mead 算法外)在本质上都是完全随机的。因此,DST 与 AO 直接相关。

2. 上文已经回答。我再补充一点,测试使用的测试函数可以满足我们的需要。这一点对实现当前目标非常重要。想象一下,我们有能力对所有可能的集合执行所有可能的运行,即执行一次完整的枚举。现在想象一下,你需要选择其中的一部分,对吗?如何选择呢?- 有一些标准可供您从所有参数中进行选择。如果您知道要从完整搜索得到的所有可能参数(解决方案)中选择哪些参数(解决方案),那么您就知道在优化过程中要应用哪些标准。标准的作用由 FF 来实现。

应用什么样的 FF 才能确保系统的稳健性?- 优化算法无法回答这个问题,也从未回答过这个问题。只有当你知道要寻找什么时,优化算法才能帮助你找到答案。

选择 FF 的责任完全在于研究人员。

关于高频质量对 AO 结果的影响的问题曾多次出现在本论坛和其他论坛上,我一直没有在公共领域看到这个问题的答案,现在答案出现了,而且还提供了验证工具。
 

优化被许多神话、滥用和误解所笼罩,因此我想再次重申:

让我们做一个心理实验。通过完全枚举,可以得到系统参数的所有可能变体。 在这种情况下,完全排除了优化算法,绝对不存在优化算法。 在掌握了所有可能的参数变体之后,问题来了:该选择哪些参数?- 知道了这个问题的答案,就有可能以合适度函数的形式从所有可能的变体中描述选择标准,而合适度函数已经可以应用于优化过程。这样,优化算法就能获得所需的结果,与全面搜索相同,但速度更快。在进行了这个心理实验之后,我们可以清楚地看到,优化算法并没有因为它的发现而 "有罪",有罪的是没有准确描述所需标准的用户。

这一点非常重要。

 
Andrey Khatimlianskii #:

它比 git 更好。你可以查看版本历史,轻松查看每个文件的所有改动,还可以报告问题或对某一行代码发表评论,等等。

很高兴在评论者中看到你,安德烈。

使用 github 并不容易,动力和时间都是问题))。

 
Andrey Dik #:

很高兴在评论者中看到你,安德鲁。

使用 github 并不容易,动力和时间都是问题))。

有趣的话题!

使用 github -- 最多一天的学习和实验时间,然后就是纯粹的享受了。随时准备提供帮助。


Andrey Dik#:

优化被许多神话、滥用和误解所笼罩,因此我想再重复一遍:

让我们做一个心理实验。通过完整的枚举,可以得到系统参数的所有可能变量。 在这种情况下,完全排除了优化算法,绝对不存在优化算法。 在掌握了所有可能的参数变体之后,问题来了:应该选择哪些参数?- 知道了这个问题的答案,就有可能以合适度函数的形式从所有可能的变体中描述选择标准,而合适度函数已经可以应用于优化过程。这样,优化算法就能获得所需的结果,与全面搜索相同,但速度更快。在进行了这个心理实验之后,我们可以清楚地看到,优化算法并没有对它所发现的结果 "有罪",而是用户没有准确描述所需的标准。

这一点非常重要。

为了支持斯坦尼斯拉夫的观点。

FF 无法描述它周围的空间,它没有来自外部的信息。

而研究人员的任务不是找到一个结果参差不齐的尖峰,而是找到一个结果差别不大的高原。

FF 如何确定自己在空间中的位置?它不能,它只知道自己的绝对坐标。因此,我们需要一种算法(如果听起来不顺耳,也可以称之为 "不优化算法"),这种算法不是寻找最大值(尽管是全局的),而是寻找最佳高原。当然,"最佳 "的定义是另一个有趣的问题,但显而易见的是,来自高原中心的参数比来自被护城河环绕的尖峰的参数在前进过程中要稳定得多。

 
Andrey Khatimlianskii #:

支持斯坦尼斯劳的想法。

FF 无法描述它周围的空间,它没有来自外部的信息。

而研究人员的任务不是找到一个结果参差不齐的尖峰,而是找到一个结果差别不大的高原。

FF 如何确定自己在空间中的位置?它不能,它只知道自己的绝对坐标。因此,我们需要一种算法(如果听起来不顺耳,也可以称之为 "不优化 算法"),这种算法不是寻找最大值(尽管是全局的),而是寻找最佳高原。当然,"最佳 "的定义是另一个有趣的问题,但显而易见的是,来自高原中心的参数比来自被护城河环绕的尖峰的参数在前进过程中要稳定得多。

斯坦尼斯拉夫说的和你现在说的都与优化无关。你也没有正确理解适配函数的某些方面。不过,你同意将优化与突出颜色分开已经很不错了。

看来需要专门写一篇单独的文章来讨论这些问题。

不过,我们还是从这里开始讨论吧。我们再假设一次,我们有机会进行一次完整的系统参数扫描。我们用所有可能的原则参数对系统历史进行一次运行。现在,请回答这个问题:"您是否有办法从所有可能的参数中选择一组(或几组)您愿意用于在新数据上运行系统的参数?这个问题不仅是问你,也是问所有愿意回答这个问题的人。正如我们所看到的,现在我们讨论的根本不是任何优化算法,而只是选择一组参数在未知数据上运行系统。

 
Andrey Dik #:

假设我们可以对系统参数进行全面搜索。我们在系统历史上运行所有可能的原则参数。现在,请回答以下问题:"您是否有办法从所有可能的参数中选择一组(或几组)参数,以备在新数据的系统运行中使用?

我只选择当地高山的山顶(不是悬崖)。