Create 0112-path-sum.md #29
Conversation
| ### 実装1 | ||
|
|
||
| - アルゴリズムの選択 | ||
| - BFS/DFSであらゆる経路について素直に葉まで足し合わせ、葉でtargetSumになればreturn Trueすれば良さそう。 |
There was a problem hiding this comment.
もし葉でtargetSumになるような経路を返却するとしたらどうでしょうか？
設問としてはTrue/Falseなのですが、単純にTrue/Falseを得るよりはpathを実際に知るほうが意味があるのかなと思ったので...自分が面接だったら質問しそうです。
There was a problem hiding this comment.
follow-upありがとうございます。
そうですね、通ったノードのその時点の和を記録するsetまたは辞書を持つようにし、ゴールの葉からスタートに向かって再びBFS/DFSするのが（空間）計算量が節約できて良さそうですね。
さらに、そのようなpathの総数/pathを全部知りたい場合は、1回目の前向きの探索をearly returnなしで完遂し、和の記録も通った回数を辞書で記録しておくのが良さそうに思います。
| if root is None: | ||
| return False | ||
|
|
||
| frontiers = deque() |
There was a problem hiding this comment.
私は英語に詳しくないのですが、なんだか開拓という感じがしてロマンを感じるなと思いました。探索だと結構使われることもあるのですね。
chromiumのコードにもfrontiersは出てきますね。
There was a problem hiding this comment.
その感覚わかります、"queue"が標準モジュールにあるので、語感が好きなfrontiersを第一候補にしがちです。
なるほど、そうなんですね。
| - > 現在は取り出し後に total += node.val。読みやすさを優先するなら、キューには「次に検査する時点での合計」を積むか、 | ||
| - 積む時点で加算する場合、足し算の位置がコード中で分散してしまうのが好みでない。 | ||
| - > あるいは subtractive 形式で「残り」を積むと、葉の判定が1行で済みます。 | ||
| - これは思いつかなかった。しかし、差に注目するのは不必要にロジックを複雑化させているように感じてしまう。 |
There was a problem hiding this comment.
再帰の場合は引数のtargetSumを減らして呼ぶのが自然なので発想として出てきますが、whileで書く場合はスタックに積むか親のnodeに戻るときに足して戻すか、というのが必要になって複雑な印象になりますね。
（加算でも、結局戻す処理をしてるのは一緒かもしれないですが）
There was a problem hiding this comment.
ありがとうございます。
再帰の場合は引数のtargetSumを減らして呼ぶのが自然なので発想として出てきますが
これは気づきませんでした、その通りですね。
whileで書く場合はスタックに積むか親のnodeに戻るときに足して戻すか、というのが必要になって複雑な印象になりますね。
そうなんですよね。個人的に最近はなるべくiterativeに書くようにしているのもあり。
この問題：https://leetcode.com/problems/path-sum/
次の問題：https://leetcode.com/problems/binary-tree-level-order-traversal/