アルゴリズムの漸近的複雑性とアルゴリズム設計の実践との関連性の説明

アルゴリズムと複雑さでは、アルゴリズムの漸近的な複雑さ、つまり、入力のサイズが無限大になるときにアルゴリズムが使用するリソースの量に焦点を当てます。

実際には、必要なのは、有限の（場合によっては非常に多数の）インスタンスで高速に動作するアルゴリズムです。

関心のある有限数のインスタンスで実際にうまく機能するアルゴリズムは、優れた漸近的複雑さを持つ必要はありません（有限数のインスタンスでの良好なパフォーマンスは、漸近的複雑性に関して何も意味しません）。同様に、優れた漸近的複雑さを備えたアルゴリズムは、関心のある有限数のインスタンスでは実際にはうまく機能しない可能性があります（たとえば、大きな定数のため）。

なぜ漸近的な複雑さを使用するのですか？これらの漸近解析は、実際のアルゴリズムの設計にどのように関連していますか？

興味深い質問は、代替手段は何ですか？私が知っている他の唯一の方法は、テスト/ベンチマークです。アルゴリズムをプログラムし、有限入力セット（の代表サンプル）で実行させ、結果を比較します。それにはいくつかの問題があります。

• 結果は、マシンに関して一般的ではありません。別のコンピューターでベンチマークを実行すると、確実に、定量的に、そしておそらく定性的にも異なる結果が得られます。
• 結果は、プログラミング言語の観点からは一般的ではありません。言語が異なれば、結果も大きく異なります。
• 結果は、実装の詳細に関して一般的ではありません。アルゴリズムではなく、文字通りプログラムを比較します。実装の小さな変更により、パフォーマンスに大きな違いが生じる可能性があります。
• 最悪のケースがまれな場合、ランダムな入力サンプルに不良インスタンスが含まれていない可能性があります。平均的なケースのパフォーマンスに関心がある場合はそれで問題ありませんが、一部の環境ではワーストケースの保証が必要です。
• 実際には、入力セットは変更されます。通常、入力は時間とともに大きくなります。6か月ごとにベンチマークを繰り返さない場合（はい、一部のデータはそれほど速く成長します）、結果はすぐに価値がなくなります¹。

そうは言っても、分析ではあらゆる種類の効果と定数を無視するのが一般的ですが、（練習に関して）怠calledと呼ぶことができます。これは、与えられた（擬似コードでも）実装のパフォーマンスを正確に特定するよりも、アルゴリズムのアイデアを比較するのに役立ちます。これは粗雑であり、よく見ることがしばしば必要であることはコミュニティによく知られています。たとえば、クイックソートは、（非常に）小さな入力の挿入ソートよりも効率が低くなります。公平を期すため、通常、より正確な分析は困難です ²。

別の、形式的で抽象的な視点に対する事後的正当化は、このレベルでは物事がしばしばより明確になるということです。したがって、数十年の理論的研究により、実際に使用される多くのアルゴリズムのアイデアとデータ構造が生み出されました。理論的に最適なアルゴリズムは、常に実際に使用したいものではありません。他にも考慮すべき点がありますが、実行するパフォーマンスは異なります。フィボナッチヒープを考えてみてください-そして、このラベルはユニークでさえないかもしれません。算術式の最適化に関心のある典型的なプログラマーにとって、このレベルで新しいアイデアを思い付くのは困難です（それが起こらないとは言いません）ただし、同化されたアイデアに対してこれらの最適化を実行できます（実行する必要があります）。

ある程度練習するためのギャップを埋めるための正式な理論的ツールがあります。例は

• メモリ階層（およびその他のI / O）を考慮し、
• 平均ケースの分析（適切な場合）、
• （抽象的なコスト測定の代わりに）個々のステートメントの数を分析し、
• 一定の要因を決定します。

たとえば、Knuthはさまざまなステートメントの数を文字通りカウントすることで（特定のモデルの特定の実装に対して）知られており、アルゴリズムの正確な比較が可能です。このアプローチは抽象的なレベルでは不可能であり、より複雑なモデルでは実行が困難です（Javaを考えてください）。最新の例については、[4]を参照してください。

理論と実践の間には常にギャップがあります。現在、両方の長所を組み合わせてアルゴリズムのコストと実行時間（平均）の両方の健全な予測を行うことを目標にツール³に取り組んでいますが、これまでは1つのアルゴリズムがより高いシナリオを廃止することはできませんでしたコストは同等ですが、ランタイムは（一部のマシンでは）小さくなります（ただし、それを検出し、理由の発見をサポートできます）。

ベンチマークを実行する前に、実践者が理論を使用してアルゴリズムの空間をフィルタリングすることをお勧めします。

if ( input size forever bounded? ) {
  benchmark available implementations, choose best
  schedule new benchmarks for when machine changes
}
else {
  benchmark implementations of all asymptotically good algorithms
  choose the best
  schedule new benchmarks for when machine changes or inputs grow significantly
}

1. キャッシュミスの数が増えると、絶対的なパフォーマンスと相対的なパフォーマンスに大きな変化が生じる可能性があります。これは通常、入力が増えてもマシンは同じままであるときに起こります。
2. 同様に、この分野の主要な研究者はそれを行うことができません。
3. ここでツールを見つけます。使用例は、Engineering Java 7のDual Pivot Quicksort Using MaLiJAnにS. Wildなどによって公開されています。（2012）[ プレプリント ]
4. S. WildとM. NebelによるJava 7のDual Pivot Quicksortの平均ケース分析（2012）-[ preprint ]

この質問は、漸近解析を含むコースを教えることから生じると思います。この教材が入門クラスで教えられる理由に関して、いくつかの可能な答えがあります。

• 漸近解析は、解析にそれ自体をもたらす数学的抽象化です。（ほぼ間違いなく）数学者として、私たちはアルゴリズムを分析できるようにしたいと考えています。彼らは複雑さを抑える方法としては漸近分析を使用しています。

• アルゴリズムの漸近的パフォーマンスの評価は、実際に役立ついくつかの原則を指摘しています。たとえば、コードの大部分の時間を費やす部分に集中し、漸近的に無視できる部分を占めるコードの部分を割引きます。 。

• 漸近解析のテクニックのいくつかは有用です。ここでは、主にいわゆる「マスター定理」について言及していますが、これは多くの場合、現実の良い説明です。

• 歴史的な理由もあります。人々が最初にアルゴリズムを分析し始めたとき、彼らは漸近的な複雑さが実際の使用法を反映していると真剣に考えていました。しかし、最終的には間違っていることが判明しました。同じことが、Pが効率的に解決可能な問題のクラスとして、NPが難治性の問題のクラスとして発生しましたが、どちらも実際には誤解を招くものです。

個人的には、漸近解析はカリキュラムの合理的な部分だと思います。より疑わしい部分には、形式言語理論と複雑性理論（チューリングマシンに関係するもの）が含まれます。一部の人々は、これらの主題はプログラマーにとっては役に立たないが、優れた実務家になるために必要な特定の思考を彼女に植え付けていると主張しています。他の人は、理論が時々練習に影響を与えると主張します、そして、これらのまれなケースは一般的なコンピュータ科学聴衆にこれらのむしろ不可解な主題を教えることを正当化するのに十分です。私はむしろ、彼らに歴史や文学、あるいは彼らが実際に興味を持っている他の主題を学んでもらいたい。どちらも彼らの将来の仕事の見通しに関連しており、人間にとってより重要です。

実行時間の漸近分析を使用する重大な理由は2つあります。

• $n$

• 数学的な扱いやすさを可能にします。操作カウントの正確な式を見つけることができるような場合は例外です。漸近を研究すると、より多くの可能性が開かれます（複雑な関数の漸近近似が便利なように）。

また、他にも多くの機能があります（マシンの独立性、有意性、比較可能性など）。

Raphaelの回答で述べたように、最悪の場合の実行時間を正確に計算することは非常に困難です。RAMモデルにはすでに近似値が導入されているため、正確な計算も不要になる場合があります。たとえば、すべての操作に本当に同じ時間がかかりますか？特定の実装（ハードウェア、最適化）は、一定の要因によりアルゴリズムを高速化する可能性があります。アルゴリズムがこれらの要因から独立している効果を理解したいと思います。これは、漸近解析を使用する大きな動機です。

漸近は「単純」であるため（とにかく、有限の場合の正確な分析を行うよりも単純です）。

たとえば、すべての重要なアルゴリズム（およびそれほど重要ではない多くのアルゴリズム）の詳細な分析を行うKnuthの百科事典「The Art of Computer Programming」を、漸近的な推定を得るのに十分な経験則分析と比較してください（ほとんどの「アルゴリズム」の本で実践されているように。

あなたは確かに正しいです。問題が十分に重要な場合は、Knuthスタイル（またはおそらく少し詳細ではない）の分析が必要になるでしょう。多くの場合、実験データに適合漸近複雑にヒント（分散と恐らく平均）が十分です。では、ほとんどの場合、行うには大分類最初の雑草アウトラウンド比較漸近が正確に十分なように、競合するアルゴリズムのを。競争相手がいない場合、正確なコストの悪いニュースを詳細に把握することは、ただのマゾヒズムです。

ここで、漸近解析により、入力のサイズが無限大になるときのアルゴリズムの動作を意味すると仮定します。

漸近解析を使用する理由は、実際にアルゴリズムの動作を予測するのに役立つため です。予測を使用すると、たとえば、使用すべき問題に対して異なるアルゴリズムがある場合に、決定を下すことができますか？（有用であることは、常に正しいということではありません。）

現実世界の単純化されたモデルについても同じ質問をすることができます。なぜ現実世界の単純化された数学モデルを使用するのですか？

物理学について考えてください。古典的なニュートン物理学は、現実世界の予測において相対論的物理学ほど良くありません。しかし、それは車、高層ビル、潜水艦、飛行機、橋などを構築するのに十分なモデルです。例えば、衛星を構築したり、宇宙探査機をPl王星に送信したり、動きを予測したりする場合星や惑星のような巨大な天体や、電子のような非常に高速の天体。 モデルの限界を知ることは重要です。

1. 通常、これは実世界の十分な近似値です。 実際には、より良い漸近解析を備えたアルゴリズムが実際にうまく機能することがよくあります。アルゴリズムの漸近的挙動が優れていることはめったにないため、入力が十分に大きくなる場合は、通常、アルゴリズムの挙動の最初の予測として漸近的解析に頼ることができます。入力が小さくなることがわかっている場合はそうではありません。必要なパフォーマンスに応じて、より慎重な分析を行う必要がある場合があります。たとえば、入力の分布に関する情報がある場合、アルゴリズムが提供されます。目標を達成するためにより慎重な分析を行うことができます入力の％）。ポイントは、最初のステップとして、漸近解析が開始点として適しています。実際には、パフォーマンステストも行う必要がありますが、それにも問題があることに留意してください。

2. $A$$A$$A$より良い漸近的な複雑さを持ちます。すべての入力において、どれも他より優れているものは何ですか？それからそれはよりトリッキーになり、私たちが気にするものに依存します。大きな入力または小さな入力を気にしますか？大きな入力を気にする場合、アルゴリズムの漸近的複雑性は向上しますが、気になる大きな入力では最悪の動作をすることは一般的ではありません。小さな入力をもっと気にかけている場合、漸近解析はそれほど有用ではないかもしれません。気になる入力のアルゴリズムの実行時間を比較する必要があります。実際には、複雑な要件を持つ複雑なタスクの場合、漸近解析はそれほど有用ではない場合があります。アルゴリズムの教科書で扱っている簡単な基本的な問題については、非常に便利です。

簡単に言えば、漸近的複雑度は、単純な基本タスク（アルゴリズムの教科書の問題）のアルゴリズムの実際の複雑度の計算が比較的簡単です。より複雑なプログラムを構築するにつれて、パフォーマンス要件が変化し、より複雑になり、漸近解析はそれほど有用ではない場合があります。

アルゴリズムのパフォーマンスを予測し、それらを比較するために、漸近解析を他のアプローチと比較するとよいでしょう。一般的なアプローチの1つは、ランダムまたはベンチマーク入力に対するパフォーマンステストです。漸近的複雑性の計算が困難または実行不可能な場合、たとえば、SAT解法のようなヒューリスティックを使用している場合は一般的です。別のケースは、要件がより複雑な場合です。たとえば、プログラムのパフォーマンスが外部要因に依存し、私たちの目標は、一定の制限時間内に終了するもの（たとえば、ユーザーに表示されるインターフェイスの更新について）入力。

ただし、パフォーマンス分析にも問題があることに注意してください。アルゴリズムに与えられるすべての入力でパフォーマンステストを実際に実行する（より多くの場合、計算的に実行不可能である）場合のパフォーマンスに関する数学的な被授与者を提供しません（そして、いくつかの入力が決して与えられないことを決定することはしばしば不可能です）。我々はランダムなサンプルや私たちが暗黙的にされているベンチマークに対してのテストをした場合と仮定すると、いくつかの規則性 アルゴリズムの性能については、すなわちアルゴリズムは、パフォーマンステストの一部ではない他の入力にも同様に行います。

パフォーマンステストの2番目の問題は、テスト環境に依存することです。つまり、プログラムのパフォーマンスは入力だけで決定されるのではなく、外部要因（マシンの種類、オペレーティングシステム、コーディングされたアルゴリズムの効率、CPUの使用率、メモリアクセス時間など）によって決まります。同じマシンでのテスト。繰り返しますが、パフォーマンステストが実行される特定の環境は、プログラムを実行するすべての環境でパフォーマンステストを実行しない限り、実際の環境と同様であると想定しています10年後にアルゴリズムがオンになりますか？）。

$\Theta(n \lg n)$$\Theta(n^2)$$\Theta(\lg n)$$O(n)$

$O(n^2)$$O(n \log n)$$O(n^2)$ クイックソートと比較して終了するため。

ここで、コードが呼び出された回数だけコードで待機が繰り返されることを想像してください。クイックソートアルゴリズムのこの明らかな優位性をどのように数学的に定量化/正当化するのでしょうか？（つまり、その名前は本当に正当化されているのですか、それとも単なるマーケティングスローガンですか？）漸近的な複雑さの測定を通じて。バブルソートは弱いアルゴリズムであり、漸近的な複雑さの分析がこれを定量的に証明できると主観的に感じているアニメーションを見てください。ただし、漸近的複雑度分析は、アルゴリズムを分析するためのツールの中の1つのツールにすぎず、必ずしも究極のアルゴリズムではないことに注意してください。

また、サイドバイサイドコードもご覧ください。bubblesortは概念的に単純であるようで、再帰を使用しません。クイックソートは、特に「3の中央値」ピボット原則よりもすぐに理解されません。バブルソートはサブルーチンなしのループで実装される場合がありますが、クイックソートは通常少なくとも1つのサブルーチンを持つ場合があります。これは、コードを単純化することを犠牲にして、より高度なコード化により漸近的な複雑さを改善できるパターンを示しています。時々、非常に大きなコードの複雑さ（thmsと正当化の証拠でいっぱいの論文全体を必要とする）が漸近的な複雑さの非常に小さな改善のみを購入する限界収益の減少（経済学からの起源）の概念に似た極端なトラドフがあります。これは、サンプルのESPとして次のように表示されます行列の乗算やグラフ化も可能です。