私はこのようなクラスカルアルゴリズムの時間の複雑さを計算しています(添付されている画像のアルゴリズムを参照してください)
T(n) = O(1) + O(V) + O(E log E) + O(V log V)
= O(E log E) + O(V log V)
as |E| >= |V| - 1
T(n) = E log E + E log E
= E log E
CLRSアルゴリズム:
それは正しいですか、何か間違っていますか教えてください。
クラスカルはO(E log E)です。あなたの派生は正しいです。また、E <= V * VであるためO(E log V)と言うこともできます。そのため、log(E)<= 2 log(V)(私がそれを覚えている理由がわかりません。ある時点で試験中...)
| V |以来> | E | + 1、E項よりもV項のタイトな上限を選択します。
|E| <= |V|²
. log |E| < log |V|²
. log |E| < 2 log |V|
. running time of MST-KRUSKAL is: O(E log V)
返事が遅れて申し訳ありません。
クラスカルアルゴリズムのランタイムはO(E log V)ではなくO(E log E)です。
エッジを最初にソートする必要があり、O(E log E)を使用して、検討中のEdgeがO(E log V)をとる安全なエッジであるかどうかを検証するランタイムを支配します。そして| E | > | V |((グラフがすでにツリーの場合は角の場合))、したがって、ランタイムがO(E log E)であると想定しても安全です
他のすべての答えは正しいですが、次の場合を考えることができます。これはO(| E |)の時間の複雑さを与えます。
次の回答は、 Dasguptaによるアルゴリズムの本 、第5章、140ページ、セクションパス圧縮からのものです。
このアルゴリズムの時間計算量の計算では、支配的な部分はO(| E | log | E |)または他のすべての回答で説明されているように、O(| E |。log | V |)。
しかし、与えられたエッジがソートされた場合はどうなりますか?
または重みが小さい場合(たとえば、O(| E |))、並べ替えを線形時間で実行できるようにします( counting sort を適用するなど)。
このような場合、データ構造部分がボトルネック(Union-find)になり、操作ごとのlog nを超えてパフォーマンスを改善することを考えると便利です。解決策は、find()操作を実行しながら、パス圧縮メソッドを使用することです。
この償却後のコストは、以前のO(log n)から、O(1)をわずかに上回る程度でした。詳細については、 このリファレンス を確認してください。つまり、vが属するセットのルートを見つけるためにfind(v)操作が呼び出されると、親へのすべてのノードのリンクが変更され、ルートを指し示します。このようにして、同じパス上の各ノードxでfind(x)操作を呼び出すと、O(1)でセットのルート(ラベル)が取得されます。したがって、この場合、アルゴリズムのボトルネックはUnion-find操作であり、記述されたソリューションを使用するとO(1)であり、記述された状況でのこのアルゴリズムの実行時間はO(| E |)です。
5行目から9行目では、複雑さはO(E)です。
5行目まで、複雑さを正しく計算しました。最後に、ここでの支配要因はO(E lg E)です。したがって、複雑さはO(E lg E)です。