ついに、FSM ライブラリへのアプリケーションが完成しました。コードのアドベント 11 年

この Advent of Code パズルは、一見単純な前提の中に巧妙に隠された、魅力的な挑戦を提示しました。 私のソリューションでは複数のアプローチを検討し、効率と有限状態マシン (FSM) ライブラリを採用する優雅さの間のトレードオフを強調しました。

このパズルには、石を表す一連の数字を操作し、数字のプロパティ (値、桁数) に基づいて 3 つの異なる変換ルールを適用することが含まれていました。 最初に、ルールをコードに直接変換する単純なソリューションを実装しました。これには、偶数桁の数値を分割し、ゼロをインクリメントし、他の数値を 2024 までに乗算する関数が含まれていました。これらの変換は、toolz.pipe と itertools.repeat を使用して連結され、「まばたき」プロセス (変換の繰り返し適用) をシミュレートしました。 25 回の瞬きを必要とするパート 1 の解決策は簡単でした。

しかし、パズルの説明は潜在的な最適化をほのめかしていました。 石の順序の維持を強調しながら、どちらの部分も点滅後の石の数のみを要求しました。この観察により、より効率的なアプローチが生まれました。 個々の石を追跡する代わりに、toolz.merge_with を使用して石の数を集計し、まばたきするたびに最終的な石の数を直接計算しました。 このカウントベースのソリューションにより、特にパート 2 の 75 回のまばたきのパフォーマンスが大幅に向上しました。

説明の目的で (および独自のライブラリをテストするために)、FSM ライブラリ Genstates を使用してソリューションを実装しました。 これには、ガード条件 (各変換ルールをチェックする関数) とアクション (変換関数自体) の定義が含まれます。 Genstates では、石の変化を状態遷移としてモデル化することができました。このアプローチは問題のロジックを明確に表現しましたが、条件チェックの短絡を許可しないライブラリの設計のため、カウントベースの方法よりも効率が低いことが判明しました。 各ステップですべての条件を徹底的にチェックするという性質が、パフォーマンスに影響を与えました。

単純なカウントベースのソリューションと FSM ベースのソリューションの比較により、最適なパフォーマンスを得るために適切なアルゴリズムとデータ構造を選択することの重要性が浮き彫りになりました。カウントベースのアプローチは、特に反復回数が多い場合に、明らかに他のアプローチよりも優れたパフォーマンスを発揮しました。 FSM 実装は洗練されていますが、主に Genstates の機能のデモンストレーションとして機能しました。

石の順序に関するパズルの微妙な誤った方向により、興味深い複雑さが加わり、問題の説明のあらゆる側面を慎重に検討することの重要性についての反省が促されました。

Microsoft Copilot によって生成された非常に不可解なイラスト

石の変化を示すステートマシン図。

著者は最後に、求人応募によって課せられる時間的制約について言及し、コーディングの実践やプロジェクトの選択に影響を与えることが多い現実世界のプレッシャーを強調しています。

以上がついに、FSM ライブラリへのアプリケーションが完成しました。コードのアドベント 11 年の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。