142. Linked List Cycle II #4

rinost081 · 2024-08-31T08:52:20Z

Linked List Cycle II を解きました。
問題: https://leetcode.com/problems/linked-list-cycle-ii/
言語: Python

レビューをお願いします。

hroc135 · 2024-09-01T01:28:34Z

lc142.py

+
+            if fast == slow:
+                slow = head
+                while(fast != slow):


while fast != slow:の方が適切だと思います。
Pythonでwhile/if文の条件式に括弧を用いるのは式が複雑で可読性を上げたい時だけで、基本的に括弧は用いないと思います。
https://google.github.io/styleguide/pyguide.html#33-parentheses

全く気にしたことがなかったところです。ありがとうございます!

h1rosaka · 2024-09-01T02:03:34Z

lc142.py

+というか、141ではset()でやって、しかも最初の方針でもset()を使うようにと書いているのになぜか今回のケースだとできなくねと判断してdict{}でやってしまっている。他のデータ構造でも代用できたと、ポジティブに捉えることができるが計算も遅いし、実装としてはあまりよろしくない。
+あ、これは問題を読み間違えていてnodeを返すのではなく位置を返すと勘違いしていることから起きたことですね。結局テストケースを試してみて位置を返すのではなくnodeを返すんじゃんと気づき、その場でdictをささっと修正して提出したのが原因なようです。落ち着きましょう。
+
+dictとset()で解いた場合、それぞれで比較してみましたが速度の違いが断然違いますね。なんでかを調べます。


これ私もわからなかったので少し調べてみました。

このサイトに下記のように記載があり、確かに重複しうるからハッシュにできなくて実質リストみたいになってて一個ずつ確認するしかないからinが遅いのかな、と私は納得しました。ハッシュが速い理由はこのサイトがわかりやすいです。

The key of the dictionary is a unique value as well as the set, and the execution time is about the same as for sets.

On the other hand, dictionary values can be duplicated like a list. The execution time of in for values() is about the same as for lists.

これは、dictで解く際に
visited_nodes: dict[int, ListNode]
ではなくて
visited_nodes: dict[ListNode, int]
等のようにListNodeをdictのキーにして、if node in visited_nodes:とかで判定すると概ね同じぐらいの速さになります。↑のコメントに書かれているようにkeysとvaluesで構造が違っています。

visited_nodes: dict[int, ListNode]の方がvisited_nodes: dict[ListNode, int]より速い理由について調べているのですが、中々良い考察を見つけられません。理由をご存知でしたら教えていただきたいです、、、。

上記の議論はPythonの辞書のkeyとvalueの探索の違いについて書かれています。
辞書の中から任意のkeyを探索するのにかかる時間はO(1)です。なぜなら、Pythonの辞書はハッシュマップで実装されており、任意のkeyに対してハッシュ値を計算してその値を元にメモリ空間の中からこのkeyはここに格納されているはずと決め打ちできるからです。
一方、任意のvalueを探索しようと思うと、辞書の中に格納されているすべてのvalueを舐めるように探索するしか方法がないので、O(n)時間かかります。
つまり、辞書型はkeyの探索の方がvalueの探索より断然速いです。なので、visited_nodesの中から任意のListNodeを探索する必要があるのならListNodeをvalueではなくkeyに設定した方が良いということだと思います

なるほどそういうことなのですね。ずっとintの方がListNodeよりも速いという理解をしていたのでその理由を考えていました。そうではなくて探索をするときにkeyを見るか、valueを見るかという話ということなのですね。ありがとうございます。

ちなみに #4 (comment) で記載されている「より速い」の順序が逆になっています！

タイポですね、、、指摘ありがとうございます!

nodchip · 2024-09-01T02:24:49Z

lc142.py

+
+class Solution:
+    def detectCycle(self, head: Optional[ListNode]) -> Optional[ListNode]:
+        visited_node = {}


複数の値が格納される変数の変数名は複数形で終えたほうが、中に複数の値が含まれていることが分かりやすくなり、読んでいる人にとって読みやすく感じられると思います。

nodchip · 2024-09-01T02:26:53Z

lc142.py

+
+"""step2
+141のコードレビューで指摘された、最初にアルゴリズムを言語化するというのはできたが、時間計算量と空間計算量を概算するという過程を忘れていたので、次回では忘れずにやりたい。
+解答を見る感じだと141みたいにフロイドの循環アルゴリズムを使う方法があるっぽい。だけど理由がわからない。


フロイドの循環アルゴリズムはソフトウェアエンジニアの常識には含まれていないと思います。 set() を用いた解法が書ければ十分だと思います。

そうなんですね。ちなみに、常識に含まれていないアルゴリズムや解法を調べるのは趣味の範疇としてそこまで気にしなくて良いものなのでしょうか。それとも常識がある人たちは、趣味の範疇と切り捨てずに出てきたものはくまなく調べ上げるものなのでしょうか? 常識がある人たちの意識がどこにあるのかをお聞きしたいです。

人によると思います。自分の場合は、気になったものは調べますし、そうでないものは頭の片隅に置いておく程度にとどめると思います。

面接官から見ると、速い人と遅い人で速度が10倍違うので、速い人のために時間つなぎがしたくなることがあるんですよ。そういうときに、パズル要素があると、パズルを説明したりしていると時間が使えるので、そこが評価ポイントでなかったとしても便利なんです。また、受けている人を歓待したいという気持ちがあります。少なくとも、自社にいい印象を持っている人を怒らせて帰す必要はないですからね。転職が多い業界でいつ一緒に働くかは分からないわけですし。
一方で、それを体験した人はパズル部分が印象を残すので、そこが強く評価されたポイントだったのではないかと思う傾向があります。

sasanquaneuf · 2024-09-01T06:44:51Z

lc142.py

+https://github.com/h1rosaka/arai60/pull/4#discussion_r1722542513　プライベートメソッドだとアンダースコアをつけるのが普通なんですね。
+
+というか、141ではset()でやって、しかも最初の方針でもset()を使うようにと書いているのになぜか今回のケースだとできなくねと判断してdict{}でやってしまっている。他のデータ構造でも代用できたと、ポジティブに捉えることができるが計算も遅いし、実装としてはあまりよろしくない。
+あ、これは問題を読み間違えていてnodeを返すのではなく位置を返すと勘違いしていることから起きたことですね。結局テストケースを試してみて位置を返すのではなくnodeを返すんじゃんと気づき、その場でdictをささっと修正して提出したのが原因なようです。落ち着きましょう。


これは重要な気づきだと思います。
一般論として、「がんばって書いたコード」を書き上げた瞬間は、それまでの思考の経緯に引きずられて、変な構造や冗長な記述がコードに含まれています。
こうして思考の経緯を言語化すると、「posからnodeへのdictを元々作っていたため、valuesを使って解いてしまった（が、valuesはlistと同等の構造のため、inで探すのには適していない）」といった具合で整理できてとても良いですね。

前回のコードレビューで、思考ログを書くと良いとアドバイスされたのでやってみました。見直しをするときにかなり役立ちそうですね。

主題と関係ないのですが、この問題に関しては問題文が少し理解しづらいので、気持ちはわかります。。。
面接ではこの辺を書き始める前に擦り合わせておくことは重要そうですね。

Mike0121 · 2024-09-02T11:07:22Z

lc142.py

+
+class Solution:
+    def detectCycle(self, head: Optional[ListNode]) -> Optional[ListNode]:
+        visited_node = set()


nodesの方が良いかと思います。

複数のオブジェクトを扱うときは変数名も気をつけた方が良さそうですね、ありがとうございます

rinost081 added 2 commits August 30, 2024 20:15

step1

0fae907

step2, step3

f7865da

hroc135 reviewed Sep 1, 2024

View reviewed changes

h1rosaka reviewed Sep 1, 2024

View reviewed changes

nodchip reviewed Sep 1, 2024

View reviewed changes

sasanquaneuf reviewed Sep 1, 2024

View reviewed changes

Mike0121 reviewed Sep 2, 2024

View reviewed changes

rihib mentioned this pull request Sep 6, 2024

Linked List Cycle rihib/leetcode#31

Merged

rinost081 changed the title ~~Leet code142~~ 142. Linked List Cycle II Dec 5, 2024

142. Linked List Cycle II #4

Are you sure you want to change the base?

142. Linked List Cycle II #4

Conversation

rinost081 commented Aug 31, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

h1rosaka Sep 1, 2024 • 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!

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!

Uh oh!

h1rosaka Sep 1, 2024 •

edited

Loading