323. Number of Connected Components in an Undirected Graph by atmaxstar · Pull Request #9 · atmaxstar/coding_practice

atmaxstar · 2026-05-10T04:23:53Z

Number of Connected Components in an Undirected Graph
問題:https://neetcode.io/problems/count-connected-components/question
言語: Python3

liquo-rice

コードと日本語での説明が一致していないところが多数ありそうです。

liquo-rice · 2026-05-10T05:33:49Z

+            roots.add(unionFind.find(i))
+        return len(roots)
+```
+UnionFindを何も見なくても実装できるように言語化してみる。まずUnionFindの初期化ではサイズnと0からn-1までの各ノードの属する集合のルートをフィールドとしてもつ。各ノードの親は最初は各ノード自身を指定させる。findメソッドでは引数に入れたノードの集合のルートを求めて返すのだがノードAを引数にもらった際に単にself.parents[A]を求めた場合に親がノードBとして、ノードBがさらに親を持つ場合、再帰的に親の親を求めてノードが自分自身を親とする所まで遡る必要がある。またノードAの親を求める時に再びその再帰のプロセスを行うのは非効率なので、self.parent[node]を最終的な親に書き換えておく。


まずUnionFindの初期化ではサイズnと0からn-1までの各ノードの属する集合のルートをフィールドとしてもつ。

コードと一致していないように見えますが、この説明で合っていますか？

def __init__(self, n): self.parent = list(range(n)) self.rank = [1]*n

最初self.n = nと書いていたのですが途中で書き換えてしまったので一致しなくなってしまいました...

liquo-rice · 2026-05-10T05:35:35Z

+            self.rank[pu] += self.rank[pv]
+        else:
+            self.parent[pu] = pv
+            self.rank[pv] += self.rank[pu]


これだとunion by rankではなく、union by sizeではないですか？

本当ですね。NeetCodeの回答を参考にしたのですがあちらもrankを使っているけどもunion by sizeをしているみたいです。self.sizeに変名した方がいいですね。

liquo-rice · 2026-05-10T05:37:33Z

+            self.rank[pu] += self.rank[pv]
+        else:
+            self.parent[pu] = pv
+            self.rank[pv] += pu


+= self.rank[pu]ですか？

間違ってますね...
puがintだったのでエラーが出ず見逃してました。

liquo-rice · 2026-05-10T05:40:15Z

+
+        return answer
+```
+空間計算量はO(2*E + N), 時間計算量はO(2*E + N)である。(Eはedgesのサイズ、Nはノードの数)


Big O記法で定数倍は省略するのが一般的だと思います。

liquo-rice · 2026-05-10T05:41:27Z

@@ -0,0 +1,188 @@
+## step1:
+それぞれの集合の数を求めていくということで、Union Findを使うんだろなと思ったがUnion Findの実装方法をすっかり忘れてしまった。そこでDFSを使って各ノードを探索していくことにする。双方向グラフなのでお互いのノードに対してベクトルを辞書型で置いていき、深さ優先探索で辿っていく。edgesをfor文で回してもし辿ったことのないノードだったらそこで探索をし、そのグラフを探索済みのものとしてanswerをインクリメントしていく。


双方向グラフなのでお互いのノードに対してベクトルを辞書型で置いていき

これがどういう意味なのか、文からは分かりませんでした。

liquo-rice · 2026-05-10T05:42:25Z

@@ -0,0 +1,188 @@
+## step1:
+それぞれの集合の数を求めていくということで、Union Findを使うんだろなと思ったがUnion Findの実装方法をすっかり忘れてしまった。そこでDFSを使って各ノードを探索していくことにする。双方向グラフなのでお互いのノードに対してベクトルを辞書型で置いていき、深さ優先探索で辿っていく。edgesをfor文で回してもし辿ったことのないノードだったらそこで探索をし、そのグラフを探索済みのものとしてanswerをインクリメントしていく。


edgesをfor文で回してもし辿ったことのないノードだったらそこで探索

コードと一致していないように見えますが、どこに相当しますか？

すいません、途中で方針を変えて言ってることが食い違ってしまうことが多々ありますね...
今回の場合は
「0からn-1までのノードを巡り辿ったことのないノードだったらそこで探索」
ですね。

liquo-rice · 2026-05-10T05:43:19Z

+            roots.add(unionFind.find(i))
+        return len(roots)
+```
+UnionFindを何も見なくても実装できるように言語化してみる。まずUnionFindの初期化ではサイズnと0からn-1までの各ノードの属する集合のルートをフィールドとしてもつ。各ノードの親は最初は各ノード自身を指定させる。findメソッドでは引数に入れたノードの集合のルートを求めて返すのだがノードAを引数にもらった際に単にself.parents[A]を求めた場合に親がノードBとして、ノードBがさらに親を持つ場合、再帰的に親の親を求めてノードが自分自身を親とする所まで遡る必要がある。またノードAの親を求める時に再びその再帰のプロセスを行うのは非効率なので、self.parent[node]を最終的な親に書き換えておく。


self.parent[node]を最終的な親に書き換えておく

最終的な親=ルートですかね？

そうですね、最終的な親に名付けるならルートかなと思いました。

liquo-rice · 2026-05-10T05:45:09Z

+        return len(roots)
+```
+UnionFindを何も見なくても実装できるように言語化してみる。まずUnionFindの初期化ではサイズnと0からn-1までの各ノードの属する集合のルートをフィールドとしてもつ。各ノードの親は最初は各ノード自身を指定させる。findメソッドでは引数に入れたノードの集合のルートを求めて返すのだがノードAを引数にもらった際に単にself.parents[A]を求めた場合に親がノードBとして、ノードBがさらに親を持つ場合、再帰的に親の親を求めてノードが自分自身を親とする所まで遡る必要がある。またノードAの親を求める時に再びその再帰のプロセスを行うのは非効率なので、self.parent[node]を最終的な親に書き換えておく。
+unionメソッドは2つのノードを引数とし、それぞれが属している集合を合体させるのだが、もし合体させようとしてる2つのノードのルートが同じノードだった場合、それはその集合はすでに同一であることの証なので早期リターンする。もしparentが違ったら集合を合体させる。単に片方のルートのparentをもう片方のルートに設定すればいいのだが、集合のノード数が少ない方のルートの親を集合のノード数が多い方のルートに指定した方がself.parentの更新数が少なくなるのでself.rankを比較してノード数の多い方のルートを中心に結合する。この際に、結合された方のランクを結合する方へ加算するのを忘れない。self.findとself.unionの時間計算量はどちらもO(α(n))でほぼO(1)と同一視できるらしいが、もしself.findでの


集合のノード数が少ない方のルートの親を集合のノード数が多い方のルートに指定した方がself.parentの更新数が少なくなる

「self.parentの更新数が少なくなる」とは後のfind()を呼び出した時の話ですか？

そうですね、findで再帰的に辿ったノードのparentをルート指定するように更新する時のことを言ってますね。

liquo-rice · 2026-05-10T05:45:48Z

+        return len(roots)
+```
+UnionFindを何も見なくても実装できるように言語化してみる。まずUnionFindの初期化ではサイズnと0からn-1までの各ノードの属する集合のルートをフィールドとしてもつ。各ノードの親は最初は各ノード自身を指定させる。findメソッドでは引数に入れたノードの集合のルートを求めて返すのだがノードAを引数にもらった際に単にself.parents[A]を求めた場合に親がノードBとして、ノードBがさらに親を持つ場合、再帰的に親の親を求めてノードが自分自身を親とする所まで遡る必要がある。またノードAの親を求める時に再びその再帰のプロセスを行うのは非効率なので、self.parent[node]を最終的な親に書き換えておく。
+unionメソッドは2つのノードを引数とし、それぞれが属している集合を合体させるのだが、もし合体させようとしてる2つのノードのルートが同じノードだった場合、それはその集合はすでに同一であることの証なので早期リターンする。もしparentが違ったら集合を合体させる。単に片方のルートのparentをもう片方のルートに設定すればいいのだが、集合のノード数が少ない方のルートの親を集合のノード数が多い方のルートに指定した方がself.parentの更新数が少なくなるのでself.rankを比較してノード数の多い方のルートを中心に結合する。この際に、結合された方のランクを結合する方へ加算するのを忘れない。self.findとself.unionの時間計算量はどちらもO(α(n))でほぼO(1)と同一視できるらしいが、もしself.findでの


ノード数の多い方のルートを中心に結合する

「中心に結合する」ってどういう意味ですかね？

ここちょっと表現に迷いました。単純に、「ノード数の多い方のルートをノード数の少ない方のルートの親に指定する」と書けばよかったですね。

liquo-rice · 2026-05-10T05:47:07Z

+        def explore(x):
+            visited.add(neighbor)
+            for neighbor in x_to_neighbors[x]:
+                if not neighbor in visited:


neighbor not in visitedと書くのが一般的かと思います。

init

5adae0a

liquo-rice reviewed May 10, 2026

View reviewed changes

		@@ -0,0 +1,188 @@
		## step1:
		それぞれの集合の数を求めていくということで、Union Findを使うんだろなと思ったがUnion Findの実装方法をすっかり忘れてしまった。そこでDFSを使って各ノードを探索していくことにする。双方向グラフなのでお互いのノードに対してベクトルを辞書型で置いていき、深さ優先探索で辿っていく。edgesをfor文で回してもし辿ったことのないノードだったらそこで探索をし、そのグラフを探索済みのものとしてanswerをインクリメントしていく。

Conversation

atmaxstar commented May 10, 2026

Uh oh!

liquo-rice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

atmaxstar May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

atmaxstar May 10, 2026 •

edited

Loading