コードグラフ与えられた場合、簡約クリークグラフの計算の複雑さはどのですか？

グラフは、長さが以上のサイクルを引き起こさない場合、弦です。クリークツリーのツリーの頂点の最大クリークされた木である。のエッジは最小のセパレーターに対応します。別個のクリークツリーの数は、コードグラフの頂点の数で指数関数的になる可能性があります。$G$$4$$T$$G$$G$$T$

減少クリークグラフ 、すべてのクリーク木の組合である。つまり、すべて同じ頂点とすべての可能なエッジがあります。与えられたを計算する複雑さは何ですか？$C_r(G)$$G$$C_r(G)$$G$

が証明なしで時間で計算できると主張するプレゼンテーションを見たことがあります。これは、クリークツリーを計算するのと同じくらい簡単であることを意味します。これを確認する、またはそれを計算するためのより遅いアルゴリズムを与えるリファレンスはありますか？$C_r(G)$$O(m+n)$$G$

複雑さはO（nm）です... Gから最大クリークを計算し、それらをグラフHの頂点にします（最初はエッジなし）...次に、すべての最小セパレーターを計算し、サイズ順に並べます...最大のセパレーターを選択しますCとC 'の両方がSを含み、Hの異なる接続されたコンポーネントにある場合（最初はこれはもちろん常に真ですが、後でない）...次に次の最大のセパレータを選択して同じことを行います...すべてのセパレータが処理されるまで繰り返します...結果のグラフHはGの縮小クリークグラフです...最大クリークと最小セパレータを計算するとOになります（n + m）... O（n）クリークとO（n）セパレーターがあります...各セパレーターの処理にO（m）時間かかるため、残りの構成はO（nm）です... 。次の問題を解決できない限り、これはO（n ^ 2）以下に改善できません：グラフGが与えられると、N（u）がN（v）を含むような2つの頂点u、vを見つけます...後者は持っていないことが知られていますO（n + m）解... ...したがって、縮小クリークグラフを計算するためのO（n + m）アルゴリズムが可能であるとは考えられません...

M. Habib、J。Stachoのセクション5を参照してください。（http://www.cs.toronto.edu/~stacho/public/leafage-esa1.pdf）