漸近解析とどう違うのですか？いつ使用しますか、またその理由は何ですか？
私はこれらのようによく書かれているように見えるいくつかの記事を読みました：
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）のコストは償却済みn / 2アクションで）。
償却分析は「平均パフォーマンス」と同じではありません。償却分析は、多くのアクションを実行した場合にパフォーマンスがどうなるかを厳密に保証します。
「何」に対する答えはたくさんありますが、「なぜ」に対する答えはありません。
他の誰もが言っているように、漸近分析は、特定の操作のパフォーマンスが大規模なデータセットにどのようにスケーリングするかについてです。償却分析は、大規模なデータセットでのすべての操作のパフォーマンスの平均がどのようにスケーリングするかについてです。償却分析では、漸近解析よりも悪い範囲が得られることはなく、場合によってははるかに良い範囲が得られます。
より長いジョブの合計実行時間に関心がある場合は、償却分析のより良い範囲がおそらく気になることです。そのため、スクリプト言語（たとえば）は、コストのかかる操作であるにもかかわらず、配列やハッシュテーブルを何らかの要因で拡張できることがよくあります。（成長はO(n)操作である可能性がありますが、償却はO(1)、めったに行わないためです。）
リアルタイムプログラミングを行っている場合（個々の操作は予測可能な時間で完了する必要があります）、償却分析からのより良い範囲は重要ではありません。動作が平均して速かったかどうかは関係ありません。それが行き過ぎになる前に戻ってバンドソーを調整するのに間に合わなかった場合は...
あなたのケースでどちらが重要かは、プログラミングの問題が何であるかによって異なります。
この用語は、アルゴリズムが操作するデータ（入力）が、素人の用語では「大きくしても結論が変わらないほど大きい」という仮定の下でのアルゴリズムのパフォーマンスの分析を指します。入力の正確なサイズを指定する必要はありませんが（上限のみが必要です）、データセット自体を指定する必要があります。
これまでは、分析方法についてのみ説明してきたことに注意してください。分析している量（時間の複雑さ？空間の複雑さ？）を正確に指定しておらず、関心のあるメトリック（最悪の場合？最良の場合？平均？）も指定していません。
実際には、漸近分析という用語は、一般に、アルゴリズムの上限時間計算量、つまり、big-Oh表記で表される合計実行時間で測定される最悪の場合のパフォーマンスを指します（たとえば、ソートアルゴリズムはO(nlogn)）。
この用語は、最悪のシナリオを対象とする特定の一連の操作に基づくアルゴリズムパフォーマンスの分析を指します。つまり、償却分析は、メトリックが最悪の場合のパフォーマンスであることを意味します（ただし、どの量が測定されているかはまだわかりません）。 ）。この分析を実行するには、サイズを指定する必要がありますは、入力その形式について何も仮定する必要はありません。
素人の言葉で言えば、償却分析とは、入力に任意のサイズを選択し、アルゴリズムを「実行」することです。入力に依存する決定を下す必要があるときはいつでも、最悪のパスが取られます¹。アルゴリズムが完了するまで実行された後、計算された複雑さを入力のサイズで割って、最終結果を生成します。
¹注：正確には、理論的に可能な最悪のパスです。容量がなくなるたびにサイズが動的に2倍になるベクトルがある場合、「最悪の場合」は、挿入がシーケンスとして処理されるため、挿入のたびに2倍になる必要があると想定することを意味しません。既知の状態を使用することが許可されています（実際に使用する必要があります）入力が不明なままであっても、をて、「さらに悪い」ケースをできるだけ多く数学的に排除。
漸近分析と償却分析の重要な違いは、前者は入力自体に依存し、後者はアルゴリズムが実行する操作のシーケンスに依存することです。
したがって：
O(1)。
これに対する答えは、本の「償却分析」の章の最初の文で簡潔に定義されています-アルゴリズムの概要：
で償却解析、時間は、データ構造の操作のシーケンスはすべての操作が実行にわたって平均さ実行するために必要。
プログラムの成長の複雑さを漸近解析で表します。これは、プログラムの成長を関数で制限し、その最悪、最良、または平均的なケースを定義します。
しかし、これは、プログラムの複雑さがピークに達するケースが1つしかない場合には誤解を招く可能性がありますが、一般に、プログラムは多くの計算を必要としません。
したがって、1回の操作でコストがかかる場合でも、一連の操作でコストを平均化する方が理にかなっています。これは償却分析です！
償却分析は、複雑さの計算に使用される漸近手法の代替手段です。これは、2つ以上のアルゴリズムを比較して決定するために、実用性の観点からより真の複雑さを計算するのに役立ちます。
アルゴリズムの償却分析を理解するためにこれまでに見つけた最良の参考資料は、「アルゴリズムの概要」、第3版、第17章「償却分析」にあります。それはすべてそこにあり、StackOverflowの投稿にあるものよりもはるかによく説明されています。この本は、まともな大学の図書館にあります。
通常の漸近解析では、問題のサイズの関数として、個々の操作のパフォーマンスを漸近的に調べます。O（）表記は、漸近解析を示すものです。
償却分析（漸近分析でもあります）は、共有データ構造に対する複数の操作の全体的なパフォーマンスを調べますます。
違いは、償却分析は通常、M回の操作に必要な合計計算が、個々の操作の最悪の場合のM倍よりも優れたパフォーマンス保証を持っていることを証明します。
たとえば、サイズNのスプレーツリーでの個々の操作には、最大O（N）時間がかかる場合があります。ただし、サイズNのツリーに対する一連のM操作は、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））に相当します。したがって、償却原価はより安価です。
簡単に言えば、早い段階で少し余分に費やすことで、後で大幅に節約できます。