63. Unique Paths II#10
Conversation
| // 統一すると行数が増えてしまうのでこうしている。 | ||
| // (L57をif(!obstacle...にすると{}でくくる必要があり、3行に増える) | ||
| // が、あんまりよくないだろうか?(良くない気がするが聞いてみたい) | ||
| // (行数は無駄に増やさない方が読みやすいと思っている) |
There was a problem hiding this comment.
行数を増やさないようにするはあんまりしませんね。
これは、Haskell で一行で解いてますが分かりにくいでしょう。
https://docs.google.com/document/d/11HV35ADPo9QxJOpJQ24FcZvtvioli770WWdZZDaLOfg/edit?tab=t.0#heading=h.kqo7dp4vlnzh
| // - 他の人のPRを見ていてnum_paths[0][*]やnum_paths[*][0]の初期化処理を | ||
| // 途中でbreakさせることが出来ることに気づいた。 | ||
| // でも個人的にはこっちの方が(一貫性があってDPとしての)ロジックが分かりやすいかなぁと。 | ||
| // - ロジックに問題があるわけではないので反復はレビューをもらってからしたい。 |
There was a problem hiding this comment.
これ、やってみると分かると思いますが、自分の頭の中の流れが素直に表現されているものは「反復しやすい」です。
コーディングは知的な行為というよりは体を動かすのに近いので、(武術の)投げ方のように何度か試してみると自然な方法が見つかります。
私は、そういう意味で少しの反復がこの練習の中核だと思っています。一回3分位でできるでしょう。
There was a problem hiding this comment.
うーん、確かにです。
レビュー前の間違いを含んでいるかもしれないものを反復しても仕方ないと思っていたんですが、反復すること自体に意味がある、反復する回数は多い方がいいかもしれませんね。
3分ぐらいならすぐに出来ますし、これからやってみることにします!
ありがとうございます!
There was a problem hiding this comment.
別に唯一の正解があるわけではないので、そんなに私の書き方を鵜呑みにしないほうがいいでしょう。
たぶん、これは目的から考えたらいいと思います。
最終目的は「仕事の場に出て問題なく一緒に仕事ができること」です。
コードが絡む場面は大きく2つあって、書くところと読むところです。
書くところは、「ある程度の時間で書ける。動くだけではなく、書いたコードが変更しやすく周りの人に分かりやすくしておくなどの基準で。」で、読むところは、「色々な書き方をすんなり読めるようにしておく。」でしょう。
(もちろん、仕事で出会うことが非現実的な問題もあるけれども、)仕事の場で出会ったら、自分はどのように振る舞うだろうかという話です。
There was a problem hiding this comment.
一回目書いて他の人のコードを読むと「ボードゲームでいえばルール、全体像が分かった」状態になります。では、仮にこの知識、現在の視点があったら、はじめに自分はどう振る舞っていたであろうか、どう振る舞っていたらよかったか、それを二回目三回目あたりで考えてみるとよいだろうと思っています。
やってみた結果、一切改善点が見つからないならば、そもそも、不要な練習なのかもしれません。
という風に考えています。しかし、とはいえ、練習の仕方は好きなようにしたらいいと思っています。
There was a problem hiding this comment.
別に唯一の正解があるわけではないので、そんなに私の書き方を鵜呑みにしないほうがいいでしょう。
いやーそれなんですが…、自分一人でコードを書くという経験は結構やってきたなと思っていまして。
自分だけで出せる答えはすでに出しているかなと思っています。
書くところは、「ある程度の時間で書ける。動くだけではなく、書いたコードが変更しやすく周りの人に分かりやすくしておくなどの基準で。」で、読むところは、「色々な書き方をすんなり読めるようにしておく。」でしょう。
この目的と全く同じではありませんが、リーダブルコードが示すことは意識して3年ぐらいはコードを書いてきたつもりです。
でも、それは全て一人で、僕の中で出してきた答えや癖でしかなく、でも、僕にとってはそれが正解に見えているという状況になっています(他のエンジニアから大きく不正解なものが正解になっているかもしれない)。
なのでこの限界を超えるために、誰か一人のすでにエンジニアとなっている人の癖を完コピしてでも、一旦矯正をしてその上で色々考えたいなという思いがあります。
(自分はどうやったって客観になり得ませんし。)
※尤もArai60は3年間で書いてきていないものばかりなので、それ自体は自分でもまだまだ答えを出せていないものばかりです。
↑上で言っているのは、アルゴリズムなどではなく、もっと細かい部分(言語で言うニュアンスみたいな...)の話です。
(でも、これについては書くことだけじゃなく読むことも必要そう?)
とはいえ、練習の仕方は好きなようにしたらいいと思っています。
はい、これ(教育/学習)に関しては人それぞれ相性というものがあると思っているので、様々な意見を試しながら、自分に合う方法を探していきたいと考えています!
一回目書いて他の人の...
なるほどです!(多分どっかに書いてあったんだろうと思うんですが)知らなかったのでこの学習スタイルの意図は正直理解せずのままでした。
教えてくださりありがとうございます!
| vector<vector<int>> num_paths(height, vector<int>(width)); | ||
| num_paths[0][0] = 1; | ||
| for (int i = 1; i < height; ++i) { | ||
| if (!obstacleGrid[i][0]) num_paths[i][0] = num_paths[i - 1][0]; |
There was a problem hiding this comment.
自分なら
if (obstacleGrid[i][0]) {
break;
}
num_paths[i][0] = 1;とすると思いました
注意
ファイルが複数ある場合、<番号>.cppの<番号>が最も大きいものが最新版です!
最新版のみレビューお願いします!(もちろん過去のものをレビューしていただいても構いませんmm)
問題
https://leetcode.com/problems/unique-paths-ii/description/?envType=problem-list-v2&envId=xo2bgr0r