20. Valid Parentheses（251019) #6
Conversation
Walkthroughスタックとマップを使った単一パスの括弧妥当性検証 Changes
Sequence DiagramsequenceDiagram
participant User as 入力文字列
participant Validator as isValid(アルゴリズム)
participant Stack as スタック
participant Result as 結果
User->>Validator: 括弧列を送信
Note over Validator: 1文字ずつ処理
alt 文字が開き括弧
Validator->>Stack: プッシュ(対応する閉じ括弧を期待)
else 文字が閉じ括弧
Validator->>Stack: トップを取得
alt トップが対応する開き括弧
Stack->>Validator: ポップして続行
else スタック空または不一致
Validator->>Result: false を返す
end
end
Note over Validator: 全文字処理完了
alt スタックが空
Validator->>Result: true を返す
else スタック非空
Validator->>Result: false を返す
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 分 Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
20.ValidParentheses_251019.md (1)
34-36: open_to_closeマッピングの選択は適切です
open_to_closeマッピングが推奨される理由：開き括弧を見つけたときにスタックに積み、後で対応する閉じ括弧を検証するというアルゴリズムの流れに自然に合致します。close_to_openの場合、閉じ括弧を見つけたときにスタックトップをルックアップする必要があり、直感的ではなく、逆引きの複雑さが増します。現在のアプローチは標準的で理解しやすいものです。3～4ヶ月後に独立して異なるアプローチを思いついたことは、問題理解が深まった証です。LeetCodeの模範答案を確認する前に、このアプローチを完成させることは良い学習戦略です。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
20.ValidParentheses_251019.md(1 hunks)
🔇 Additional comments (1)
20.ValidParentheses_251019.md (1)
3-32: 初回の試行が学習プロセスの価値を示している初回の解答は完成していませんが、括弧マッチングの問題本質を理解し、辞書ベースのアプローチを検討している様子が伝わります。スタック手法への発展につながる有益な思考過程です。
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
20.ValidParentheses_251019.md (1)
95-95: 参考リンクをMarkdownリンク形式で記述してください。Static analysis hint: MD034 (bare URL detected)
行95の参考リンクを括弧で括り、リンク形式に統一します：
- - https://github.com/h1rosaka/arai60/pull/8/files + - [参考: プッシュダウンオートマトン](https://github.com/h1rosaka/arai60/pull/8/files)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
20.ValidParentheses_251019.md(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
20.ValidParentheses_251019.md
95-95: Bare URL used
(MD034, no-bare-urls)
🔇 Additional comments (2)
20.ValidParentheses_251019.md (2)
74-91: 修正版のスタック実装は正確で適切です。括弧の優先度を明示する括弧を追加することで、前のバージョンの問題を解決しました（89行目）。アルゴリズムは以下の点で正確です：
- 開き括弧をスタックに積み、対応する閉じ括弧の期待値を構築
s == correct_sで入力文字列と一致確認len(open_brackets_stack) == 0で未クローズ括弧がないか確認括弧のネスト、不一致、未クローズのケースをすべて正しく処理します。
60-71: 問題の自己診断と修正の説明が優れています。Pythonの三項演算子の優先度を正確に分析し、問題を特定し、修正理由を明確に記録しました。このような問題を発見して対応できる能力は重要です。
| correct_s = correct_s + char | ||
| else: | ||
| correct_s = correct_s + open_to_close[open_brackets_stack.pop()] if open_brackets_stack else "#" | ||
| return s == correct_s and len(open_brackets_stack) == 0 |
There was a problem hiding this comment.
まあ、いいんですが、s == correct_s にならない条件ってなんですかね。
open_to_close[open_brackets_stack.pop()] のあたりでもう分かりませんか。
| open_brackets_stack.append(char) | ||
| correct_s = correct_s + char | ||
| else: | ||
| correct_s = correct_s + open_to_close[open_brackets_stack.pop()] if open_brackets_stack else "#" |
There was a problem hiding this comment.
if 文と参考演算子が混在しているせいで読みにくく感じました。また、 1 行が長すぎるように感じました。 if 文で書き下したほうが読みやすくなると思います。
| correct_s = correct_s + char | ||
| else: | ||
| correct_s = correct_s + open_to_close[open_brackets_stack.pop()] if open_brackets_stack else "#" | ||
| return s == correct_s and len(open_brackets_stack) == 0 |
There was a problem hiding this comment.
Implicit false を利用し、
return s == correct_s and not open_brackets_stackと書くことをおすすめします。
参考までにスタイルガイドへのリンクを貼ります。
https://google.github.io/styleguide/pyguide.html#2144-decision
For sequences (strings, lists, tuples), use the fact that empty sequences are false, so if seq: and if not seq: are preferable to if len(seq): and if not len(seq): respectively.
上記のスタイルガイドは唯一絶対のルールではなく、複数あるスタイルガイドの一つに過ぎないということを念頭に置くことをお勧めします。また、所属するチームにより何が良いとされているかは変わります。自分の中で良い書き方の基準を持ちつつ、チームの平均的な書き方で書くことをお勧めいたします。
| if char in open_to_close: | ||
| open_brackets_stack.append(char) | ||
| correct_s = correct_s + char | ||
| else: | ||
| correct_s = correct_s + (open_to_close[open_brackets_stack.pop()] if open_brackets_stack else "#" ) |
There was a problem hiding this comment.
correct_s = correct_s + char ですが、forループを書き下すと '' + 's[0]' + 's[1]' + ... + 's[-1]' のようなイミュータブルなシーケンスの結合になっており、パフォーマンスの観点から避けるべきだと思います。
イミュータブルなシーケンスの結合は、常に新しいオブジェクトを返します。これは、結合の繰り返しでシーケンスを構築する実行時間コストがシーケンスの長さの合計の二次式になることを意味します。実行時間コストを線形にするには、代わりに以下のいずれかにしてください:
- str オブジェクトを結合するには、リストを構築して最後に str.join() を使うか、 io.StringIO インスタンスに書き込んで完成してから値を取得してください
...
https://docs.python.org/ja/3.13/library/stdtypes.html#string-methods
| correct_s = correct_s + char | ||
| else: | ||
| correct_s = correct_s + (open_to_close[open_brackets_stack.pop()] if open_brackets_stack else "#" ) | ||
| return s == correct_s and len(open_brackets_stack) == 0 |
There was a problem hiding this comment.
correct_sという変数を設けずに実装する方がシンプルに感じます。
具体的にはopen_to_close[open_brackets_stack.pop()]とcharを比べることで、適切な閉じカッコかを確認します。そうすればループ中に不正な文字が来た時点で処理を打ち切ることができ、最後にはlen(open_brackets_stack) == 0の比較だけで済みます。
|
|
||
| (2回目の回答の修正) | ||
| ```python | ||
| class Solution(object): |
There was a problem hiding this comment.
Python3では、class Solution: で大丈夫です。
もしかすると、leetcodeの設定がpython3になっていないのかもしれません。
pythonとpython3の２つが選べるようになっており紛らわしいのですが、昨今はpython3が主流と思われるので、特別な理由がなければpython3を選んでおいたほうが良さそうです。
|
レビューありがとうございます。レスが遅くなり申し訳ありません。 |
問題リンク：https://leetcode.com/problems/valid-parentheses/description/
3、4ヶ月ぶりに解いたところ、初回の回答(leetcodeの模範回答)とは別の方法で解いてしまったため、改めてレビューをお願いしたいです。
Summary by CodeRabbit