機能的なプログラミングにおいて、永続的な広さの木が特に役立つのはなぜですか?
-
27-10-2019 - |
質問
に 広さの木 ウィキペディアページ それは言われています(利点セクションで):
Splay Treesの永続的なデータ構造バージョンを作成する可能性。これにより、更新後に以前のバージョンと新しいバージョンの両方にアクセスできます。 これは、機能プログラミングに役立ちます, 、および更新ごとに償却o(log n)スペースが必要です。
何故ですか?機能的なプログラミング特性はどのように使用されていますか 永続的な広さの木?
解決
現代の機能プログラミングの運転目標の1つは、州のより良い管理であり、おそらく必要な限り使用しないようにします。これは、ステートフルプログラムがエラーを避けるために正しいシーケンスでコマンドを慎重に実行する必要があるためです。
永続的なデータ構造は、それらが可変状態を使用しないため、正確に優れています。
//mutable tree
var t = new_tree();
add(t, 1);
add(t, 2);
//the tree has now changed so if anyone was depending on the old value
//we will now have a problem
//persistent tree
var t = new_tree();
var t2 = add(t, 1);
var t3 = add(t2, 2);
//t1 and t2 have not changed
あなたが指摘した引用は、純粋な機能プログラミングで永続的なデータ構造が一般的に使用されている(そして好ましい)ことを強調することです。この場合、広がった木については何の具体もありません。
他のヒント
あなたの質問は、永続的に不幸な用語の混乱から来ているようです。より良いフレーズはそうかもしれません 純粋に機能的です, 、つまり、破壊的な突然変異のない機能的プログラミング。混乱は、さまざまな理由で、機能的なプログラミング全体で不変の永続的なデータ構造がより一般的であるという事実から生じる可能性があります。
要するに、おそらくそのフレーズは、「不変のデータ構造のみを使用してプログラミングする場合に永続的なスプレイツリーを作成することが役立つ」と読むことができます。
私は反対のことを主張することさえ、スプレイツリーは機能的なプログラミングで作業するのが快適ではありません。なぜなら、あなたはすべての操作を見つけるたびに新しいツリーを返す必要があるからです。また、私が知っているすべての検索ツリーは、操作ごとにO(log n)追加スペースで機能的に直接使用できます。その文の唯一の興味深い事実は、操作あたりのメモリ要件が常にa(log n)を償却したままであると思います。