这个《代码的降临》谜题提出了一个令人着迷的挑战，巧妙地隐藏在看似简单的前提下。 我的解决方案探索了多种方法，强调了使用有限状态机 (FSM) 库的效率和优雅之间的权衡。
这个谜题涉及操纵代表石头的数字序列，根据数字的属性（值、位数）应用三种不同的转换规则。 最初，我实现了一个简单的解决方案，直接将规则转换为代码。这涉及到到 2024 年分割偶数、增加零以及乘以其他数字的函数。这些转换使用 toolz.pipe 和 itertools.repeat 链接在一起，以模拟“眨眼”过程 - 重复应用转换。 第 1 部分的解决方案需要眨眼 25 次，非常简单。
然而，谜题的描述巧妙地暗示了潜在的优化。 在强调保存棋子顺序的同时，双方都只要求眨眼后计数棋子。这一观察导致了一种更有效的方法。 我没有跟踪单个石头，而是使用 toolz.merge_with 聚合它们的数量，直接计算每次眨眼后的最终石头数量。 这种基于计数的解决方案显着提高了性能，尤其是第 2 部分的 75 次眨眼。
出于说明目的（并测试我自己的库），我还使用我的 FSM 库 Genstates 实现了该解决方案。 这涉及定义保护条件（检查每个转换规则的函数）和操作（转换函数本身）。 Genstates 允许将石头转换建模为状态转换。虽然这种方法提供了问题逻辑的清晰表示，但由于库的设计不允许条件检查的短路，事实证明它比基于计数的方法效率较低。 检查每个步骤中所有条件的详尽性会影响性能。
简单的、基于计数的和基于 FSM 的解决方案之间的比较强调了选择正确的算法和数据结构以获得最佳性能的重要性。基于计数的方法明显优于其他方法，特别是对于大量迭代。 FSM 实现虽然优雅，但主要用作Genstates功能的演示。
谜题关于石头顺序的微妙误导增加了一层有趣的复杂性，促使人们反思仔细考虑问题描述的各个方面的重要性。
由 Microsoft Copilot 生成的非常神秘的插图
说明石头转换的状态机图。
作者最后提到了工作申请所施加的时间限制，强调了经常影响编码实践和项目选择的现实世界压力。
以上是最后，我的 FSM 库的应用程序！ 11 月 11 日代码的出现的详细内容。更多信息请关注PHP中文网其他相关文章！
