1. 12/10/16 Study/PFDS/7-Eliminating Amortization
Study/PFDS/7-Eliminating Amortization
7 Eliminating Amortization
これまでは、操作列全体が効率良くシンプルであることに注目してきた。
Raman[92] によると・・・
個々の操作の実行時間が極端に長くならないことが重要な応用分野が存在する
このような分野では、ならしデータ構造よりもワーストケースのデータ構造が多くの場合望ましい。
1. リアルタイムシステム
2. 並列システム - 高価な操作により他のプロセッサを待たせることになる
3. インタラクティブシステム - しばしばスピードよりも一貫性が重視される
4. 永続データ構造
しかし、ならし解析は永続データ構造と相性が良いことがこれまでの議論で分かっている
ならしデータ構造はワーストケースよりも単純なので、
ワーストケースで最初から作るよりも
いったんならしデータ構造を設計した後で、
ワーストケースに変換するほうが簡単な場合が時々ある。
「スケジューリングの手法とは」
遅延コンポーネントをシステマティックに評価（force)して、
遅延の実行時間があまり長くならないようにすることで、
遅延ならしデータ構造をワーストケースのデータ構造に変換する手法
すべてのオブジェクトをスケジュールと呼ばれる要素で拡張して、
遅延コンポーネントが評価される順序を規則づける。
kinug.com/wiki/Study/PFDS/7-Eliminating Amortization 1/5

2. 12/10/16 Study/PFDS/7-Eliminating Amortization
7.1 Scheduling
「ならしデータ構造とワーストケースのデータ構造との違い」
ワーストケースのデータ構造では、
操作内のすべての計算がその操作の間に実行される。
ならしデータ構造では、
操作内の一部の計算が後の操作の時に実行される。
このことから見て、
完全な遅延評価言語でインプリメントされた場合、
多くの計算が必要以上に遅延されることから、
ならしとみなすことができる。
真のワーストケースのデータ構造をあらわすためには、
正格な言語(strict language)が必要である。
「遅延評価と正格評価の両方をサポートする言語を用いた複合的アプローチ」（の提案）
内部で遅延評価を行うワーストケースのデータ構造
遅延された慣らしデータ構造を元に、
すべての操作が割り当てられた時間内に実行されるように修正を加える
「遅延の本質コストを定義」（準備）
まずは、以下の仮定の下で各遅延の本質コストを定義する
他のすべての遅延が評価済みでメモ化されている
他のすべての遅延がO(1)
これは unshared cost に類似
kinug.com/wiki/Study/PFDS/7-Eliminating Amortization 2/5

3. 12/10/16 Study/PFDS/7-Eliminating Amortization
「最初のステップ」（コストの調節）
全ての遅延の本質コストを要求された限界よりも小さくする
例えば次のような方法
基本的なアルゴリズムを変更
モノリシックな関数のみに対応した表現をインクリメンタルなものに書換える
（例：遅延リスト(suspended lists)→ストリーム(streams))
「連鎖反応」（コストが高くなるケース）
遅延が他の遅延に依存している場合には計算に時間がかかる
例
(・・・((s1 ++ s2) ++ s3) ++ ・・・) ++ sk
一番外側の ++ から返される遅延を評価すると、
全ての ++ を一気に実行する連鎖反応が起きる。
→O(k)
注：ドミノ倒し
一つのドミノを倒すコストが O(1) だとしても、
全てのドミノを倒すコストはずっと大きい
kinug.com/wiki/Study/PFDS/7-Eliminating Amortization 3/5

4. 12/10/16 Study/PFDS/7-Eliminating Amortization
「二つ目のステップ」（評価のスケジューリング）
遅延を評価する時点で、
その遅延が依存する他の遅延が全て評価され
メモ化済みであるようにする。
->数珠繋ぎの評価を回避
注：ドミノ倒し
ドミノを倒したときに、次のドミノがすでに倒れているようにしておく。
そうすると個々のドミノを倒すコストは小さい
手順：
全てのオブジェクトを schedule と呼ぶ追加の要素で拡張
schedule は、オブジェクトに含まれる全ての未評価の遅延へのポインタを
(少なくとも概念的に)含む。
schedule に評価済みの遅延が含まれても問題はない(早くなるだけ)。
全ての操作は、そのオブジェクトに対して行われる他の全ての操作に加えて、
スケジュールに含まれる最初の少しの遅延を評価する。
このとき評価する遅延の数はならし解析によって決められる(governed)。
多くの場合、全ての遅延はO(1)時間を実行に要するので、
その操作のならしコストに比例した数の遅延を評価する。
データ構造によっては、スケジュールの管理(方法?)は自明でない。
この手法を適用するために、新しい遅延をスケジュールに加えたり、
評価すべき次の遅延を取得したりするために、
定められたワーストケース境界以上の時間を要することはできない。
kinug.com/wiki/Study/PFDS/7-Eliminating Amortization 4/5

5. 12/10/16 Study/PFDS/7-Eliminating Amortization
まとめ
個々の操作の実行時間を一定以内に抑えたい
ならしの手法で作ったアルゴリズムを変換する方法を提案する
1. 操作の本質コストを定義
2. 各操作のコストを要求仕様に合わせる
アルゴリズムの変更
インクリメンタルな処理を行えるようにする
3. 遅延の評価タイミングの制御
オブジェクトを「スケジュール」要素で拡張して
未評価の遅延へのポインタを保持させる
各操作で「スケジュール」に含まれる遅延を前もって消化
kinug.com/wiki/Study/PFDS/7-Eliminating Amortization 5/5