償却分析？（最悪の場合の性能保証）

償却分析とは何ですか？また、プログラムで最悪の場合のパフォーマンス保証を達成するのにどのように役立ちますか？

私は、次のテクニックがプログラマーが最悪のパフォーマンス保証を達成するのを助けることができると読んでいました（つまり、私自身の言葉：プログラムの実行時間が最悪のキャストの実行時間を超えないことを保証します）：

• ランダム化アルゴリズム（たとえば、最悪の場合、クイックソートアルゴリズムは2次ですが、入力をランダムに並べると、実行時間が線形であることが確率的に保証されます）
• 操作のシーケンス（分析では、データとクライアントが実行した操作のシーケンスの両方を考慮する必要があります）
• 償却分析（パフォーマンス保証を提供する別の方法は、すべてのオペレーションの合計コストをオペレーション数で割って追跡することにより、コストを償却することです。この設定では、平均コストを維持しながら、いくつかの高価なオペレーションを許可できますつまり、少数の高価な操作のコストを、その一部を多数の安価な操作のそれぞれに割り当てることで分散します）

著者は、償却分析を達成する方法の1つの例として、Stackの配列データ構造のサイズ変更の使用に言及しましたが、償却分析とは何か、実際にはどのようにできるかはまだわかりません最悪の結果を達成するために実装か（データ構造？アルゴリズム？） -キャストパフォーマンス保証

償却分析を実装しません。より正確に取得するための手法ですO境界です。

あなたがしなければならない本質的な観察は、高価な操作はいつでも起こらないということです。

配列に裏打ちされたデータ構造の場合、配列は時々満杯になるとサイズを変更する必要があります。これは最も費用のかかる操作であり、時間がかかりますO(n)。配列への他のすべての挿入はO(1)です。

nアイテムを挿入するためのランタイムを決定するためにn、最も高価な操作で乗算することができますO(n)で。これにより、の全体的なランタイム動作が得られO(n^2)ます。

ただし、サイズ変更はあまり頻繁に行われないため、これは不正確です。

お金について話すとき、あなたは償却しますときは、時間をかけて複数回の小額の支払いで借金を返済するときにコストします。

このモデルを使用して、アルゴリズムについても考えることができます。メンタルマッピングを避けるために、単に「時間」を「お金」に置き換えます。

配列がその長さに満たされるとn、サイズを2倍にできます。次の操作を行う必要があります。

• 2nメモリのチャンクを割り当てる
• コピーnアイテム

メモリの割り当てとコピーの両方が線形時間で発生すると仮定すると、これは非常に高価な操作になります。ただし、負債の概念を使用して、分析のためにそれを償却することができます。ただ、私たちは実際にそれを達成する前に借金を償却します。
配列のサイズを変更したら、（お金/時間の）残高が0に戻ったと仮定しましょう（つまり、借金も残余もありません）。

これには次の意味があります。

• 次のnアイテムを挿入すると、サイズ変更とコピーのコストがカバーnされます（使用済みスロットとn未使用スロットがあります）

これで、すべての挿入操作の費用を考えることができます。

• インサート
• メモリの1つのチャンクを割り当てるコスト
• 新しく割り当てられたメモリに移動するコスト

これで、メモリの割り当て、次のn要素のコピーおよび挿入のコストをカバーできました。ただし、古いn要素にスペースを割り当てたり、コピーしたりすることはまだ怠っています。

古いn要素のコストを新しい（まだ挿入される）n要素に単純に分配します。

• メモリの1つのチャンクを割り当てるコスト
• 新しく割り当てられたメモリに移動するコスト

合計で、すべての挿入操作に5ユニットのコストがかかります。これは、独自の挿入と、それ自体と古い要素の1つに対するスペースの移動と割り当ての代価を支払います。

すべての挿入操作には依然として一定の時間がかかりますが、サイズ変更は無料で行われます。挿入ごとに「より多くの」時間を費やして、それを償却しました。

その結果、n要素の挿入にはO(n)時間がかかります。

償却分析の他の手法については、ここで説明します。

まず第一に、それはアルゴリズムの実装テクニックではなく、プログラムのランタイムを分析するためのテクニックです。

リストに記載されている例は、良い例です。単一のアイテムを配列でサポートされたデータ構造に追加します。単一の追加操作ごとに、最悪の場合、既存のすべてのアイテムをコピーする必要があります。適切なサイズ変更戦略を使用している場合（サイズにx> 1.0を掛ける）必要がないので、この種の分析は悲観的すぎます。分析では、実際の実行時間はO（n）だけですが、O（n ^ 2）の制限-アイテムごとのO（n）x nアイテム-があることがわかります。

挿入されたすべてのアイテム（サイズ変更の必要のないほとんどのアイテム）のサイズ変更コストを平均すると、償却分析が行われます。償却分析の結果、アルゴリズムの実際の動作と一致するO（n）境界が得られます。