1
スプレイツリーの潜在的な機能:サイズのログを合計する理由
私はデータ構造に関するコースを教えており、来週初めにスプレーツリーを取り上げます。スプレーツリーに関する論文を何度も読んでおり、データ構造の背後にある分析と直感に精通しています。ただし、SleatorとTarjanが分析で使用する可能性のある機能について、確かな直観を見つけることはできません。 分析は、ツリー内の各要素に任意の重み割り当て、ノードのサイズs (x )をxをルートとするサブツリー内のノードの重みの合計に設定することにより機能します。次に、この値のログを取得してノードのランクr (x )を取得します。したがって、r (x )= log s (x )です。最後に、ツリーの潜在的な関数は、すべてのノードのランクの合計として定義されます。w私wiw_is (x )s(x)s(x)バツxxr (x )r(x)r(x)r (x )= ログs (x )r(x)=logs(x)r(x) = \log s(x) この潜在的な機能が正しく機能し、分析を追跡できることは理解していますが、なぜこの潜在的な機能を選択するのかわかりません。サイズを合計すると、ツリーの重み付きパス長が得られるため、各ノードにサイズを割り当てるという考えは理にかなっています。しかし、なぜ彼らが重みのログを取得し、代わりにそれらを合計することにしたのかを理解することはできません-これに対応するツリーの自然なプロパティは表示されません。 スプレーツリーの潜在的な機能は、ツリーの自然な特性に対応していますか?「うまくいく」以外に、彼らがこの可能性を選択する特別な理由はありますか?(この一連のコースノートでは、「分析は黒魔術です。[N] oがどのように発見されたか」ということに言及しているため、特に興味があります。) ありがとう!