Add 1. Two Sum.md #11
Conversation
| ```python | ||
| class Solution: | ||
| def twoSum(self, nums: List[int], target: int) -> List[int]: | ||
| num_to_index = dict() |
There was a problem hiding this comment.
{}でもdictの初期化はできますね。（こちらは構文レベルでサポートされており、dict関数の呼び出しが分、ちょっとパフォーマンス的に良かったりもします。）
There was a problem hiding this comment.
勝手に{}はdict()のsyntax sugerだと思ってました。
パフォーマンスの違い知りませんでした。
ありがとうございます。
| return [num_to_index[rest_value], i] | ||
|
|
||
| num_to_index[num] = i | ||
| raise RuntimeError( |
There was a problem hiding this comment.
RuntimeErrorは適していないような気がします。ドキュメント的には他に当てはまるものがないときの最終手段みたいな感じでしょうか
https://docs.python.org/3/library/exceptions.html#RuntimeError
Raised when an error is detected that doesn’t fall in any of the other categories. The associated value is a string indicating what precisely went wrong.
There was a problem hiding this comment.
builtin errorを使うならValueErrorですかね
https://docs.python.org/3/library/exceptions.html#ValueError
There was a problem hiding this comment.
私も ValueError のほうかなあと思いました。
ただ、大事なのは、標準ドキュメントを見て考えたかどうか、かと思います。
There was a problem hiding this comment.
コメントありがとうございます。
ValueErrorは、関数冒頭で行える様な引数チェックで引っかかる、引数が見るからに適切でない値の時（たとえば今回の問題だと、引数にくるnumsの要素数が1の時）に発生させるイメージでした。
頑張って探した（探せた）けど、求めているものが見つからない場合は、ValueErrorには当たらないのかなぁという判断でした（今回は要素数1もここに入ってしまいますが）。
ValueError: Raised when an operation or function receives an argument that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as IndexError.
とあるのでinappropriateの解釈が、ちょっと不適切だったかもしれません。
There was a problem hiding this comment.
すみません、ちょっと関連して私見を述べたくなったのでコメントさせていただきます
(この認識が違っていたら講師役の方に訂正を願いたいです)
こういったもの(エラー以外の例はあんまり思いつきませんが)の方針は、出来るだけより詳細を示せるエラーの型を選ぶとよいと僕は思っています。
なぜなら、エラー文が人間が理解しやすいもの、エラーの型等はコンピューターが理解しやすいもの、といった認識があるからです。
RuntimeErrorにしてしまうと、もしこの関数の中で他にRuntimeErrorをraiseする関数があったら、コンピューター(この関数のエラーをキャッチする呼び出し元)にとってはエラー文を読むことでしか区別が出来ません。
でも、ValueErrorやよりシチュエーションを正確に表すエラーの型なら、他と被る確率を下げることが出来ます。
※また、この関数でRuntimeErrorを2か所以上raiseしなければいいというわけでもなく、この関数と一緒に他のRuntimeErrorをraiseする関数と一緒にtry-catchブロックに入れることでも同じ問題が起きます。
究極、(言い過ぎかもしれませんが)型は人間の認識と少しぐらいずれていてもよく、人間にとってはエラー文の方が本命だと思っています。
There was a problem hiding this comment.
try-catchブロックの中で細かい粒度で例外を捉えられるようにという意識があまりなかったです。勉強になります。
| return [num_to_index[rest_value], i] | ||
|
|
||
| num_to_index[num] = i | ||
| raise RuntimeError( |
There was a problem hiding this comment.
すみません、ちょっと関連して私見を述べたくなったのでコメントさせていただきます
(この認識が違っていたら講師役の方に訂正を願いたいです)
こういったもの(エラー以外の例はあんまり思いつきませんが)の方針は、出来るだけより詳細を示せるエラーの型を選ぶとよいと僕は思っています。
なぜなら、エラー文が人間が理解しやすいもの、エラーの型等はコンピューターが理解しやすいもの、といった認識があるからです。
RuntimeErrorにしてしまうと、もしこの関数の中で他にRuntimeErrorをraiseする関数があったら、コンピューター(この関数のエラーをキャッチする呼び出し元)にとってはエラー文を読むことでしか区別が出来ません。
でも、ValueErrorやよりシチュエーションを正確に表すエラーの型なら、他と被る確率を下げることが出来ます。
※また、この関数でRuntimeErrorを2か所以上raiseしなければいいというわけでもなく、この関数と一緒に他のRuntimeErrorをraiseする関数と一緒にtry-catchブロックに入れることでも同じ問題が起きます。
究極、(言い過ぎかもしれませんが)型は人間の認識と少しぐらいずれていてもよく、人間にとってはエラー文の方が本命だと思っています。
https://leetcode.com/problems/two-sum/description/