漸近解析とはどう違いますか?いつそれを使用しますか、なぜですか?
次のように、よく書かれているように見えるいくつかの記事を読みました。
http://www.ugrad.cs.ubc.ca/~cs320/2010W2/handouts/aa-nutshell.pdf
http://www.cs.princeton.edu/~fiebrink/423/AmortizedAnalysisExplained_Fiebrink.pdf
しかし、私はまだこれらの概念を完全に理解していません。
だから、誰かが私のためにそれを簡素化してくれませんか?
償却分析では、呼び出し回数と1回の呼び出しの最悪の場合を単純に乗算することはありません。
たとえば、必要なときにサイズが2倍になる動的配列の場合、通常の漸近解析では、すべての要素を拡大して新しい配列にコピーする必要があるため、それに項目を追加するとO(n)がかかると結論付けられます。償却分析では、成長する必要があるため、n/2個のアイテムが前の成長以降に成長を引き起こさずに追加されている必要があるため、アイテムの追加は実際にO(1) (O(n)のコストはamortized n/2アクション以上)です。).
償却分析は「平均パフォーマンス」と同じではありません-償却分析は、多くのアクションを実行した場合のパフォーマンスの処理についてハード保証を提供します。
「何」に対する答えはたくさんありますが、「なぜ」に対する答えはありません。
他の皆が言ったように、漸近分析は、特定の操作のパフォーマンスがどのように大きなデータセットにスケーリングするかについてです。償却分析は、大規模なデータセットでのすべての操作のパフォーマンスの平均がどのようにスケーリングされるかに関するものです。償却分析は、漸近線よりも悪い境界線を与えることはありません。
長いジョブの合計実行時間に関心がある場合、償却分析のより良い範囲がおそらく気になるものです。スクリプト言語(たとえば)は、それがコストのかかる操作であるにもかかわらず、多くの場合、何らかの要因で配列とハッシュテーブルを拡大するのに喜んでいる理由です。 (成長はO(n)
操作になる可能性がありますが、めったにしないので償却はO(1)
です。)
リアルタイムプログラミングを実行している場合(個々の操作は予測可能な時間内に完了する必要があります)、償却分析のより良い範囲は重要ではありません。平均的に操作が高速であったかどうか、問題が解決するまでに間に合わずに戻ってバンドソーを調整したかどうかは関係ありません...
あなたのケースでどれが重要かは、プログラミングの問題が何であるかによって異なります。
この用語は、アルゴリズムが動作するデータ(input)が、素人の言葉で「大きくしても結論が変わらないほど十分に大きい」という仮定の下でのアルゴリズムのパフォーマンスの分析を指します。入力の正確なサイズを指定する必要はありませんが(上限のみが必要です)、データセット自体hasを指定する必要があります。
これまで、分析のmethodについてのみ説明してきたことに注意してください。どの量を分析しているのか(時間の複雑さ?スペースの複雑さ?)を正確に指定しておらず、どのmetricに興味があるかを指定していません(最悪の場合?最良の場合?平均?)。
実際には、漸近解析という用語は通常、アルゴリズムの上限時間複雑度を指します。つまり、総実行時間で測定される最悪の場合のパフォーマンスは、big-Oh表記で表されます(たとえば、ソートアルゴリズムはbe O(nlogn)
)。
この用語は、最悪の場合のシナリオ-を対象とする特定の操作シーケンスに基づくアルゴリズムパフォーマンスの分析を指します。つまり、償却分析は、メトリックが最悪の場合のパフォーマンスであることを意味します(ただし、どの数量が測定されているかはわかりません)。この分析を実行するには、入力のsizeを指定する必要がありますが、その形式について仮定する必要はありません。
素人の言葉で言えば、償却分析は、入力に任意のサイズを選択し、アルゴリズムを「再生」することです。入力に依存する決定を下す必要がある場合は常に、最悪のパスが取られます¹。アルゴリズムの実行が完了したら、計算された複雑度を入力のサイズで除算して最終結果を生成します。
¹注:正確には、最悪のパス理論的には可能。容量が使い果たされるたびにサイズが動的に2倍になるベクターがある場合、「最悪の場合」は、挿入がシーケンスとして処理されるため、every挿入時に2倍になる必要があると想定することを意味しません。入力が不明のままであっても、既知のstateを使用して、可能な限り多くの「さらに悪い」ケースを数学的に排除することができます(実際に必要です)。
漸近解析と償却解析の重要な違いは、前者は入力自体に依存し、後者はアルゴリズムが実行する操作のシーケンスに依存することです。
したがって:
これに対する答えは、本「アルゴリズムの紹介」の償却分析の章の最初の文で簡潔に定義されています。
償却分析では、一連のデータ構造操作の実行に必要な時間は、実行されたすべての操作にわたって平均されます。
漸近解析によってプログラムの成長の複雑さを表します。これは、関数によってプログラムの成長を制限し、その最悪、最良、または平均のケースを定義します。
しかし、これは、プログラムの複雑さがピークに達するケースが1つだけの場合に誤解を招く可能性がありますが、一般的に、プログラムは多くの計算を行いません。
したがって、1つの操作に費用がかかる場合でも、一連の操作全体のコストを平均する方が理にかなっています。これは償却分析です!
Amortized Analysisは、複雑さの計算に使用される漸近手法の代替手段です。 2つ以上のアルゴリズムを比較して決定するために、実用性の観点からより真の複雑さを計算するのに役立ちます。
アルゴリズムの償却分析を理解するためにこれまでに見つけた最良のリファレンスは、本にあります Introduction to Algorithms 、第3版、第17章:「償却分析」。それはすべてそこにあり、Stack Overflowの投稿で見つけることができるものよりもずっとよく説明されています。あなたはまともな大学の図書館で本を見つけるでしょう。
通常の漸近解析では、問題のサイズの関数として、個々の操作のパフォーマンスを漸近的に調べます。 O()表記は、漸近解析を示します。
償却分析(漸近分析でもある)は、共有データ構造での複数の操作のtotalパフォーマンスを調べます。
違いは、通常、償却分析では、M個の操作に必要な計算の合計が、個々の操作のM倍の最悪の場合よりも優れたパフォーマンスを保証することを証明します。
たとえば、サイズNの スプレイツリー での個々の操作は、最大O(N)時間までかかります。ただし、サイズNは、O(M(1 + log N)+ N log N)時間に制限されます。これは、操作ごとのおおよそO(log N)です。ただし、償却分析は、「平均ケース」分析よりもはるかに厳密である:あらゆる可能な操作のシーケンスが漸近的な最悪のケースを満たすことを証明します。
償却分析では、ルーチンの多数の実行にわたる総コストと、そこから得られるメリットを扱います。たとえば、単一の一致についてn個のアイテムのソートされていない配列を検索すると、最大n回の比較が必要になる可能性があるため、o(n)複雑さです。ただし、同じ配列が検索される場合m個のアイテムの場合、合計タスクを繰り返すとO(m * n)の複雑度になりますが、事前に配列を並べ替えると、コストはO(n log(n))になり、連続検索ではO(log(n))ソートされた配列の場合。このアプローチをとるm個の要素の合計償却コストはO(n * log(n)+ m * log(n))です。m> =の場合n、これはソートしない場合のO(n ^ 2)と比較して事前ソートすることでO(n log(n))に相当するため、償却コストは安くなります。
簡単に言えば、少し早めに出費することで、後でかなり節約できます。