Create 1011-capacity-to-ship-packages-within-d-days.md #27
Conversation
| - 関数名key_functionは中身に比して素朴すぎするので、可読性のために改善すべき。is_feasibleとか。 | ||
| - key_functionの計算量が悪い。weightで一重ループを回して貪欲的に区切れる。 | ||
| - 手作業でやってた時は明らかにこう考えていたのに、二分探索に囚われすぎてなぜか無理やりdayごとに二分探索する羽目になった。 | ||
| - 時間計算量: O(logC * days * log n) -> O(logC * n)に改善できる。 |
There was a problem hiding this comment.
上のやり方は自分は考え付かなかったので勉強になりました。
コードとしては実装２のほうが分かりやすく感じますが、daysがnに比べて小さい場合は上のほうが計算量が少なくなる優位性はあるのかなと考えました。
There was a problem hiding this comment.
ありがとうございます。
確かにそうですね。船が大きく一気に運ぶ前提ならアリかもしれません。
| if passed_days == days: | ||
| return False | ||
| loaded = weight |
There was a problem hiding this comment.
passed_days += 1した直後にチェックしたいという意図も分かるのですが、個人的にはloaded = weightの代入を先に書いた方が少し見やすいかなと思いました。
またパフォーマンスが問題でないのなら、このifを省いてreturnのタイミングでpassed_days < daysを判定するのもいいかなと思いました。
There was a problem hiding this comment.
ありがとうございます。
passed_days += 1した直後にチェックしたいという意図も分かるのですが、個人的にはloaded = weightの代入を先に書いた方が少し見やすいかなと思いました。
まさに、そこで悩みました。一応時系列を意識して書いてみました。今思いつきましたが、こういうのもいいかも知れません。
if passed_days + 1 == days:
return False
passed_dayes += 1
loaded = weightまたパフォーマンスが問題でないのなら、このifを省いてreturnのタイミングでpassed_days < daysを判定するのもいいかなと思いました。
これに関してはシンプルさとパフォーマンス最適化のトレードオフですが、個人的にはこの程度ならearly returnする価値が勝ると思いました。
| - Step 2で色々と参照されていて、追随側としてはありがたい。 | ||
| - [実装2](#実装2)の異常入力に対する耐性 | ||
| - weightが0や負の値であっても、例外は送出しない。 | ||
| - 負の値とかは例えば船から荷物を取り出す操作とかに対応させられそう。（ノーショー） |
| ## Step 2 | ||
|
|
||
| - レビュー by GPT-5 | ||
| - 関数名key_functionは中身に比して素朴すぎするので、可読性のために改善すべき。is_feasibleとか。 |
There was a problem hiding this comment.
ありがとうございます。
shippableも少し検討したんですが、"able"が複数日にわたる輸送計画の可能性ではなく、もっと狭い「まだ船に積むことができるか ある1日において輸送可能かどうか」のニュアンスを持つ気がして、少し違う気がしたのでふんわりとfeasibleにしてみました。
この問題：https://leetcode.com/problems/capacity-to-ship-packages-within-d-days/
次の問題：https://leetcode.com/problems/number-of-connected-components-in-an-undirected-graph/