Conversation
| if nums1[index1] < nums2[index2]: | ||
| index1 += 1 | ||
| continue | ||
| elif nums1[index1] > nums2[index2]: |
| elif nums1[index1] > nums2[index2]: | ||
| index2 += 1 | ||
| continue | ||
| # in case of nums1[index1] == nums2[index2] |
There was a problem hiding this comment.
nan == nan, nan > nan, nan < nan が全て偽なので、index1も2もインクリメントされず無限ループしますね...
if isnan(nums1[index1]) or isnan(nums2[index2]):
raise RuntimeError('The lists contain nan.')たとえばこんな感じのチェックを挟んで処理を止めるなどの処置をした方が良いかもしれません。
@oda
ちなみに、要件にもよるでしょうが小田さんだったらどう判断 (実装) しますか?nanが入ってくる場合に破綻するアルゴリズムはこれまでもあったと思っていて、どこまで考えて何を実装に反映させるかの例があると参考になりそうだと思い。
There was a problem hiding this comment.
https://discuss.python.org/t/nan-breaks-min-max-and-sorting-functions-a-solution/2868
sort, max, min 全部 nan で破綻しますよね。
ガチガチに条件を確認するというのは普通は行われていなくて(たとえば、bisect を呼ぶたびに全要素が昇順か確認していたら何の意味があるのか。)、状況次第になるわけです。
とはいえ、ゴミが返ってくるのと、停止しないのだと、ちょっと扱いは違うかなあと感じたので、一言書いてみました。
ユーザーフェイシングか否か、セキュリティー、パイプラインかリアルタイムか、それ次第で色々ですよね。
私は、ゴミが返ってもいいが、停止しないはこの場合は抵抗がありますね。
There was a problem hiding this comment.
ありがとうございます。
とはいえ、ゴミが返ってくるのと、停止しないのだと、ちょっと扱いは違うかなあと感じたので、一言書いてみました。
何となく分かる気がします。停止しないんだと異常が発生していることが分かりづらいですし、原因の切り分けも難しそうです。
自分はnanの扱いについては今までほとんど考えてこなかったので、コードに反映させるかはまた別ですが意識してみようと思います。
| if len(larger) < len(smaller): | ||
| larger, smaller = smaller, larger | ||
| intersection = [] | ||
| for num in smaller: |
There was a problem hiding this comment.
質問です。要素数の少ない方でループを回すのはどういうメリットがあるのでしょうか?
There was a problem hiding this comment.
ループ内部の処理が平均O(1)でできるので、nums1で回す (O(n1)) より要素数の少ない方で回す (O(min(n1, n2))) の方がコストを抑えられるメリットがあると思ってやりました。処理もそんなに複雑にならないしいいかな、という判断です。
setの構築ですでに要素数に対して線形にかかるので大した効果はないかもですが。
https://leetcode.com/problems/intersection-of-two-arrays/description/