関数型辞書のデータ構造を選択するにはどうすればよいですか？

次のデータ構造について少し読みました。

• バグウェルの理想的なハッシュトライ
• Larsonの動的ハッシュテーブル
• 赤黒木
• パトリシアの木

...そして他にもたくさんの人がいると思います。私はそれぞれが何に適しているのか、あるいはなぜ私が他のものを選ぶのかについてはほとんど見たことがありません。したがって、これらの行に沿っていくつかの質問があります：

1. 知っておくべき重要な関数型辞書のデータ構造は何ですか？
2. これらのアプローチの長所と短所は何ですか？
3. より命令的なデータ構造を使用するのはいつ意味がありますか？

2と3の番号がより重要です。:-)

私は迷うことなく＃2に答えることはできませんが（これらの構造を比較できる次元が多すぎるため）、＃3の答えは非常に簡単です。

（a）エイリアスがまったくない場合、または（b）効率的なブロードキャストのために本当にエイリアスを使用する必要がある場合は、命令型データ構造を使用します。

データ構造のエイリアスがまったくない場合、機能的なデータ構造が永続的であるという事実を利用していません。したがって、その費用を支払う理由はありません。このアドバイスには2つの注意点があります。まず、関数型データ構造の実装の単純さを好むかもしれません。関数型赤黒木に削除を実装すると呪いがかかりますが、親ポインターを使用して命令型赤黒木に削除を実装すると、自殺を熟考することになります。第2に、書き込みは若い世代からデータ構造を移動できるため、gc化された言語で期待するよりも割り当てが高くなる可能性があります。キャッシュエフェクトとGCの理論は実際にはありません。そのため、ベンチマークを行う以外に選択肢はありません。

次に、ブロードキャストチャネルが必要な場合は、共有データ構造が優れた方法です。一定時間の更新により、値が変更されたことを他の多くの人に任意に伝えることができます。（これが、union-findが非常に優れたデータ構造である理由です。）純粋に機能的なセットアップでは、他のすべての人々を変更するか、手動でコード化した状態に抽象的なポインタを与える必要があります（これは一種の鈍化です）やるべき事）。

エイリアスとオブジェクトの所有権について理由をつけたくない場合、または同じデータ構造の複数のバージョンが必要な場合（たとえば、新しいバージョンと古いバージョンの両方が必要な場合）は、関数型データ構造を使用します。

このアドバイスに従うのが一番難しいのは、グラフアルゴリズムです。非常に洗練された命令型グラフアルゴリズムはたくさんありますが、多くの場合（たとえば、コンパイラーを作成するとき）、永続性も必要になります。人々は通常、違いを分割し、クールな命令型アルゴリズムを使用しようとしますが、永続化するためにバージョン管理を側面にボルトで固定しようとします。これは一般にかなり恐ろしく、バグが多く、命令型アルゴリズムのパフォーマンス上の利点を失う傾向があります。

知っておくべき重要な関数型辞書のデータ構造は何ですか？

高さバランスのとれた二分木とその試行は、あらゆる点で優れた妥協策です。また：

• パトリシアの木。
• ハッシュトライ。

これらのアプローチの長所と短所は何ですか？

高さバランスのとれた二分木とそれらの試行は、アトミックキーの優れた妥協策です。文字列キーなど、シーケンスであるキーの場合も同じです。

パトリシアツリーは数倍速くなりますが、整数キーしか使用できません。

ハッシュの試行は、特に比較よりもハッシュが安く、ポリモーフィズムにオーバーヘッド（例：.NETの文字列）があり、ヒープへのポインターの書き込みが高速（例：JVMやCLRなどのVM）関数型言語ではなく命令型言語用に最適化されています）。ハッシュは、最適化としてミューテーションの内部使用も許可します。

赤黒木は、高さのバランスがとれた木に比べて大きなメリットはありませんが、効率的な結合、交差、差異ができないという大きな欠点があるため、それほど重要ではありません。

同様に、フィンガーツリーは実際にはあまり良くありません。

より命令的なデータ構造を使用するのはいつ意味がありますか？

ディクショナリが1度入力された後、ルックアップのみに使用されたとき、つまり凍結されたとき。

パフォーマンスが必要な場合（.NETのようなまともなハッシュテーブル Dictionaryは、一般的な純粋な関数型辞書よりも通常10〜40倍高速です）。

純粋に機能する弱い辞書が知られていないため、弱い辞書が必要な場合。