ランクなしのパス圧縮を使用したunion-findの複雑さ


10

ウィキペディアはパス圧縮なしのランク別組合はの償却時間複雑与え言い、そしてランクとパス圧縮することにより、両方の労働組合は、の償却時間複雑与えることをO α N αはの逆であるがアッカーマン関数)。ただし、ユニオンランクなしのパス圧縮の実行時間については触れていません。これは、私が通常自分で実装するものです。O(logn)O(α(n))α

パス圧縮最適化を使用して、ランク最適化による結合を使用しない場合のunion-findの償却時間の複雑さはどのくらいですか?


5
そのノートアッカーマン関数、ではないの逆数である1 / A N N 。ここで「逆数」とは、逆数ではなく関数としての逆数を意味します。つまり、f n = A n n α n = f 1n )の場合、1 / f n ではありません。α(n)1/A(n,n))f(n)=A(n,n)α(n)=f1(n)1/f(n)
DW

これは比較的古い質問であることを理解していますが、私の回答と関連する論文epubs.siam.org/doi/abs/10.1137/S0097539703439088を参照してください。境界を越えてコピーするときに、1つまたは2つの詳細を逃した可能性があります。その場合は、編集を提案してください:-)
BearAqua

回答:


4

SeidelとSharirは、2005年に[1]、任意のリンクでパス圧縮を使用すると、おおよそm操作でおおよそO((m+n)log(n))

[1]のセクション3(任意のリンク)を参照してください:f(m,n)が、m操作とn要素を持つunion-findの実行時間を示すとします。彼らは以下を証明した:

k>1f(m,n)(m+(k1)n)logk(n)

k=m/n+1

f(m,n)(2m+n)logm/n+1n

[2]のセクション3で、Tarjanとvan Leeuwenがより複雑な方法を使用して同様の境界を与えました。

mn(4m+n)log1+m/nn(8m+2n)log1+m/n(n).

Lemma 9 of [2]. Suppose m<n. In any sequence of set operations implemented using compression and naive linking, the total number of nodes on find paths is at most n+2mlogn+m.

[1]: R. Seidel and M. Sharir. Top-Down Analysis of Path Compression. Siam J. Computing, 2005, Vol. 34, No. 3, pp. 515-525.

[2]:R.タージャンとJ.ファンレーウェン。集合和集合アルゴリズムの最悪の場合の分析。J. ACM、Vol。31、No。2、1984年4月、245-281ページ。


2

償却実行時間が何であるかはわかりませんが、状況によっては、パス圧縮だけでなく、両方を使用したい理由の1つを挙げます。操作ごとの最悪の実行時間は Θ パス圧縮のみを使用する場合は、ランクによるユニオンとパス圧縮の両方を使用する場合よりもはるかに大きくなります。

のシーケンスを考えます 深みの木を生み出すために悪意を持って選択された連合の作戦 n1 (it is just a sequential path of nodes, where each node is the child of the previous node). Then performing a single Find operation on the deepest node takes Θ(n) time. Thus, the worst-case running time per operation is Θ(n).

In contrast, with the union-by-rank optimization, the worst-case running time per operation is O(logn): no single operation can ever take longer than O(logn). For many applications, this won't matter: only the total running time of all operations (i.e., the amortized running time) will matter, not the worst-case time for a single operation. However, in some cases the worst-case time per operation might matter: for instance, reducing the worst-case time per operation to O(logn) might be useful in an interactive application where you want to make sure that no single operation can cause a long delay (e.g., you want a guarantee that no single operation can cause the application to freeze for a long time) or in a real-time application where you want to ensure that you will always meet the real-time guarantees.

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.