111. Minimum Depth of Binary Tree by fhiyo · Pull Request #24 · fhiyo/leetcode

fhiyo · 2024-06-20T17:52:01Z

https://leetcode.com/problems/minimum-depth-of-binary-tree/description/

nodchip · 2024-06-21T09:18:29Z

111_minimum-depth-of-binary-tree.md

+
+### ①
+
+素朴に書いた。ただエッジの重みが等しいグラフ上の最短距離だから幅優先探索を思いつくのが自然な気がする (https://github.com/fhiyo/leetcode/pull/22 でも同じ状況ですぐに思いつかなかった)。


自分がこの問題を読んだときは、再帰を使った深さ優先探索を思いつきました。

余裕があれば、再帰を使った深さ優先探索でも実装してみるとよいと思います。

6fcf90dの②で書いてみました。

nodchip · 2024-06-21T09:19:43Z

111_minimum-depth-of-binary-tree.md

+    def minDepth(self, root: Optional[TreeNode]) -> int:
+        if root is None:
+            return 0
+        min_depth = float('inf')


自分も整数と浮動小数を混ぜるのは違和感を感じます。ただ、もし混ぜるのであれば、 float('inf') よりは math.inf のほうがシンプルに感じます。

float('inf') よりは math.inf のほうがシンプルに感じます。

(細かい内容の議論ではありますが...) ちなみに、nodchipさんはその2つならいつでも math.inf を選択しますか？個人的には math.inf だとinfを表すために import math を余計にやらないといけない分デメリットを感じ、避けたい気持ちがあります。今回のように何らかの理由でインポートされていれば使っても良いかなとも思いますが、やはり書き方を統一したい方が勝るんですよね...。
(NumPyにもinfがあるとかは置いておきます)

自分の場合はおそらく import math して math.inf を使うと思います。今調べたところ、 sys.maxsize というのもあるようです。チームのメンバーから同意が得られば、そちらを使うと思います。
https://docs.python.org/ja/3/library/sys.html#sys.maxsize

自分の場合はおそらく import math して math.inf を使うと思います。

なるほどありがとうございます。

今調べたところ、 sys.maxsize というのもあるようです。チームのメンバーから同意が得られば、そちらを使うと思います。

こちらはこのファイルのコメントでも言及していますが、infと比較すると有限の任意の値より大きいわけではないのでそこの弱さはあると思います。

$ python Python 3.11.3 (main, Jun 5 2023, 00:49:13) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> import math >>> 9999999999999999999999999999999999 < sys.maxsize False >>> 9999999999999999999999999999999999 < math.inf True

nodchip · 2024-06-21T09:20:10Z

111_minimum-depth-of-binary-tree.md

+        if root is None:
+            return 0
+        min_depth = float('inf')
+        node_with_depths = [(root, 1)]


node_with_depths でも大丈夫だと思いますし、 node_and_depths でも良いと思います。

細かい話ですが、複数形が気になりますね。"node with depths"なら、少しおかしい気がします。良い名前かは分かりませんが、node_depth_pairsなどはより正確な名前な気がします。

"node with depths"なら、少しおかしい気がします。

うーむなるほど。"node with depth" が複数あるという意図はきっと汲んでくれるんでしょうが、先に "node with depths" を感じるなら違和感あるでしょうね。

意図は分かるのですが、英語としては不正確そうですよね。struct NodeWithDepthがあって、それが複数あると解釈もできますが…

nodchip · 2024-06-21T09:20:46Z

111_minimum-depth-of-binary-tree.md

+        node_with_depths = [(root, 1)]
+        while node_with_depths:
+            node, depth = node_with_depths.pop()
+            is_leaf = True


変数名が動詞から始まっている点、やや違和感がありますが、 Acceptable だと思います。

また、 node.left と node.right が両方とも None のノードを見つけた時点で depth を return して early return すれば、フラグを使わずに書け、シンプルになると思います。

if not node.left and not node.right: return depth if node.left node_with_depths.append((node.left, depth + 1)) if node.right node_with_depths.append((node.right, depth + 1))

6fcf90dの①で書いてみました。

nodchip · 2024-06-21T09:24:10Z

111_minimum-depth-of-binary-tree.md

+        while node_with_depths:
+            node, depth = node_with_depths.pop()
+            is_leaf = True
+            if node.left is not None:


if node.left: でよいと思います。

一般に、二重否定は、読んでいて認知負荷が高いため、避けたほうが良いと思います。

nodchip · 2024-06-21T09:25:15Z

111_minimum-depth-of-binary-tree.md

+            nodes.append(node)
+
+        def is_leaf(node: TreeNode) -> bool:
+            return node.left is None and node.right is None


2nd のように、 return not node.left and not node.right のほうがシンプルだと思います。

nodchip · 2024-06-21T09:26:04Z

111_minimum-depth-of-binary-tree.md

+        def is_leaf(node: TreeNode) -> bool:
+            return node.left is None and node.right is None
+
+        nodes = deque()


個人的にはキューにノードと深さのタプルを入れていったほうがシンプルに感じます。

nodchip · 2024-06-21T09:27:40Z

111_minimum-depth-of-binary-tree.md

+        depth = 0
+        while nodes:
+            depth += 1
+            num_current_depth_nodes = len(nodes)


現在の深さのノードの数を保持しておき、その数だけ処理する、というのは、あまり見慣れないように思います。

キューにノードと深さのタプルを入れていく

キューを 2 つ作り、深さごとに入れ替えていく (2nd の解法)

をよく目にします。前者の方がシンプルでよいと思います。

#22 (comment)

一方、キューは 1 つだけ用意し、先頭から取り出す、末尾に入れるという形で実装することもあります。その場合、キューまたは別の領域に、何回辿ったかを表す整数を保存しておく必要があります。個人的には最近はこちらの書き方で書くことが多いです。

これ↑のコメントの「別の領域に」の方を念頭に書いてみたつもりだったのですが、見慣れないということはちょっと解釈違った感じですかね。「別の領域に」とおっしゃってるものだとどんな感じのコードになりますか？

一方で、キューが一個のものと比較すると、他の方法は多少のオーバーヘッドがありそうな気もします。

キューにノードと深さのタプルを入れていく

深さが同じものが並ぶのがメモリの無駄になりますよね。

キューを 2 つ作り、深さごとに入れ替えていく (2nd の解法)

メモリアロケーションに無駄がありますよね。例えば、std::vectorを使うなら、拡張によるコピーの回数も増えそうです。

これ↑のコメントの「別の領域に」の方を念頭に書いてみたつもりだったのですが、見慣れないということはちょっと解釈違った感じですかね。「別の領域に」とおっしゃってるものだとどんな感じのコードになりますか？

頂点情報がリストに格納されている等、頂点番号でアクセスできる場合の話になります。頂点の数を n とおいたとき、

depths = [math.inf] * n depths[begin] = 0

のように、長さ n のリストを用意しておき、頂点 begin からの経路長を格納する、といったイメージです。

なるほど。ありがとうございます 🙏

nodchip · 2024-06-21T09:28:17Z

111_minimum-depth-of-binary-tree.md

+class Solution:
+    def minDepth(self, root: Optional[TreeNode]) -> int:
+        def append_if_exists(nodes: deque[TreeNode], node: TreeNode):
+            if node is None:


コード量が少ないため、 early return しなくても良いかもしれません。

if node: nodes.append(node)

oda · 2024-06-21T15:19:22Z

111_minimum-depth-of-binary-tree.md

+        node_with_depths = [(root, 1)]
+        while node_with_depths:
+            node, depth = node_with_depths.pop()
+            is_leaf = True


私はこれ変数に置かないほうが好みですね。

111_minimum-depth-of-binary-tree

2108e49

nodchip reviewed Jun 21, 2024

View reviewed changes

oda reviewed Jun 21, 2024

View reviewed changes

111_minimum-depth-of-binary-tree 4th

6fcf90d

fhiyo force-pushed the 111_minimum-depth-of-binary-tree branch from 2e66f9a to 6fcf90d Compare June 21, 2024 18:53

goto-untrapped mentioned this pull request Jul 15, 2024

322. Coin Change #41

Open

colorbox mentioned this pull request Jan 19, 2025

111. Minimum Depth of Binary Tree colorbox/leetcode#36

Merged

TORUS0818 mentioned this pull request Jul 4, 2025

209. Minimum Size Subarray Sum ryosuketc/leetcode_arai60#38

Merged

dorxyxki mentioned this pull request Mar 23, 2026

solved: 111-minimum-depth-of-binary-tree dorxyxki/arai60#22

Open


		### ①

		素朴に書いた。ただエッジの重みが等しいグラフ上の最短距離だから幅優先探索を思いつくのが自然な気がする (https://github.com/fhiyo/leetcode/pull/22 でも同じ状況ですぐに思いつかなかった)。

Conversation

fhiyo commented Jun 20, 2024

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!

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!

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!

4 participants