他手法との比較<
/>
アルゴリズム要点（TL;DR）
- **戦略**：深さ優先探索（DFS）+ 強い枝刈り
- - 各セグメントは1〜3桁を試行
- - 残文字数の上下限チェックで早期枝刈り
- - 先頭ゼロ・255超過で即座に棄却
+ - 各セグメントは1〜3桁を試行
+ - 残文字数の上下限チェックで早期枝刈り
+ - 先頭ゼロ・255超過で即座に棄却
- **データ構造**：
- - 固定長配列 `path[4]` でセグメントを再利用
- - 事前キャッシュ `_SEG_CACHE[0..255]` で部分文字列生成を回避
+ - 固定長配列 `path[4]` でセグメントを再利用
+ - 事前キャッシュ `_SEG_CACHE[0..255]` で部分文字列生成を回避
- **計算量**：
- - 時間：O(1)（n≤20、実質的には最大 3^4=81 分岐だが強い枝刈りで大幅削減）
- - 空間：O(1)（出力を除く）
+ - 時間：O(1)（n≤20、実質的には最大 3^4=81 分岐だが強い枝刈りで大幅削減）
+ - 空間：O(1)（出力を除く）
- **メモリ最適化**：
- - スライス生成を一切行わず、キャッシュ文字列への参照のみ使用
- - 探索中の一時オブジェクト生成をほぼゼロに
+ - スライス生成を一切行わず、キャッシュ文字列への参照のみ使用
+ - 探索中の一時オブジェクト生成をほぼゼロに
---
-### フローチャート：DFS探索の流れ
+## フローチャート：DFS探索の流れ
```mermaid
flowchart TD
@@ -74,6 +76,7 @@ flowchart TD
```
**説明**：
+
- 深さ4のDFSで各セグメントを決定
- 残文字数が `[remainSegs, remainSegs*3]` の範囲外なら早期リターン
- 先頭が `'0'` なら長さ1のみ試行（`max_len=1`）
@@ -102,6 +105,7 @@ graph LR
```
**説明**：
+
- 入力検証で範囲外・不正文字を早期棄却
- DFSコアで効率的な探索（枝刈り + キャッシュ参照）
- 結果リストに有効なIPのみ蓄積
@@ -111,18 +115,22 @@ graph LR
正しさのスケッチ
**不変条件**：
+
- `path[0..seg-1]` は全て有効なセグメント（0〜255、先頭ゼロ条件満足）
- `idx` は現在処理中の文字位置、`seg` は埋まったセグメント数
**網羅性**：
+
- 各セグメントで可能な長さ（1〜3、先頭ゼロなら1のみ）を全て試行
- 枝刈りは「解が存在しない」ケースのみを除外（残文字不足/過剰、255超過）
**基底条件**：
+
- `seg == 4` かつ `idx == n`：全文字を使い切って4セグメント完成 → 解として追加
- `seg == 4` だが `idx < n`：文字が余る → 不正
**終了性**：
+
- `idx` は単調増加、`seg` も単調増加
- 最大深さ4で再帰終了
@@ -130,12 +138,13 @@ graph LR
計算量
-| 指標 | 値 | 備考 |
-|------|-----|------|
+| 指標 | 値 | 備考 |
+| -------------- | -------- | ------------------------------------------------------------------------------------------------------- |
| **時間計算量** | **O(1)** | 入力長 n≤20、各セグメント1〜3桁で最大3^4=81分岐だが、枝刈りで実際は大幅削減。出力サイズを除けば定数時間 |
-| **空間計算量** | **O(1)** | 固定長配列 `path[4]` のみ使用。再帰深さ4も定数。キャッシュ `_SEG_CACHE` はクラス変数で共有 |
+| **空間計算量** | **O(1)** | 固定長配列 `path[4]` のみ使用。再帰深さ4も定数。キャッシュ `_SEG_CACHE` はクラス変数で共有 |
**最適化の効果**：
+
- **スライス生成ゼロ**：`s[idx:idx+len]` を作らず、キャッシュ `_SEG_CACHE[val]` への参照のみ
- **逐次数値化**：`ord()` でループ内で桁を加算、`int()` 変換を回避
- **早期枝刈り**：残文字数の上下限で不可能な分岐を即座に排除
@@ -241,6 +250,7 @@ class Solution:
```
**主要ステップ**：
+
1. 入力検証（長さ・文字種）
2. DFS開始（`idx=0, seg=0`）
3. 各セグメントで1〜3桁を試行（先頭ゼロなら1のみ）
@@ -254,26 +264,27 @@ class Solution:
CPython最適化ポイント
1. **スライス回避**：
- - `s[idx:idx+len]` の代わりに `_SEG_CACHE[val]` への参照のみ
- - 探索中の一時 `str` オブジェクト生成をほぼゼロに
+ - `s[idx:idx+len]` の代わりに `_SEG_CACHE[val]` への参照のみ
+ - 探索中の一時 `str` オブジェクト生成をほぼゼロに
2. **属性アクセス削減**：
- - `SEG = self._SEG_CACHE` でローカル変数に束縛
- - ループ内での属性探索コストを削減
+ - `SEG = self._SEG_CACHE` でローカル変数に束縛
+ - ループ内での属性探索コストを削減
3. **逐次数値化**：
- - `val = val * 10 + (ord(s[i]) - 48)` で桁を加算
- - `int(s[idx:idx+len])` の変換コストを回避
+ - `val = val * 10 + (ord(s[i]) - 48)` で桁を加算
+ - `int(s[idx:idx+len])` の変換コストを回避
4. **固定長配列の再利用**：
- - `path: List[str] = [""] * 4` で固定長確保
- - push/pop せずインデックス代入のみでV8（CPython）に最適
+ - `path: List[str] = [""] * 4` で固定長確保
+ - push/pop せずインデックス代入のみでV8（CPython）に最適
5. **早期枝刈り**：
- - 残文字数の上下限チェックで不可能な分岐を即座に排除
- - `val > 255` で即座にループ脱出
+ - 残文字数の上下限チェックで不可能な分岐を即座に排除
+ - `val > 255` で即座にループ脱出
**結果**：
+
- LeetCode上で **Runtime 0ms（100%）**、**Memory 17.79MB（76.42%）** を達成
- メモリは出力リスト自体のサイズも含むため、解の個数が多い入力では不可避に増加
@@ -281,18 +292,19 @@ class Solution:
エッジケースと検証観点
-| ケース | 入力例 | 期待出力 | 検証ポイント |
-|--------|--------|----------|--------------|
-| **最小長** | `"1111"` | `["1.1.1.1"]` | 4文字で1解のみ |
-| **全ゼロ** | `"0000"` | `["0.0.0.0"]` | 先頭ゼロ許可（単独"0"） |
-| **長さ不足** | `"123"` | `[]` | n<4で即座に空リスト |
-| **長さ過剰** | `"1"*13` | `[]` | n>12で即座に空リスト |
-| **先頭ゼロ** | `"010010"` | `["0.10.0.10", "0.100.1.0"]` | 先頭ゼロは長さ1のみ |
-| **255境界** | `"25525511135"` | `["255.255.11.135", "255.255.111.35"]` | 255は有効、256は不正 |
-| **複数解** | `"101023"` | 5解（例題参照） | 全分岐の網羅性 |
-| **不正文字** | `"12a34"` | `TypeError` | 数字以外を含む入力 |
+| ケース | 入力例 | 期待出力 | 検証ポイント |
+| ------------ | --------------- | -------------------------------------- | ----------------------- |
+| **最小長** | `"1111"` | `["1.1.1.1"]` | 4文字で1解のみ |
+| **全ゼロ** | `"0000"` | `["0.0.0.0"]` | 先頭ゼロ許可（単独"0"） |
+| **長さ不足** | `"123"` | `[]` | n<4で即座に空リスト |
+| **長さ過剰** | `"1"*13` | `[]` | n>12で即座に空リスト |
+| **先頭ゼロ** | `"010010"` | `["0.10.0.10", "0.100.1.0"]` | 先頭ゼロは長さ1のみ |
+| **255境界** | `"25525511135"` | `["255.255.11.135", "255.255.111.35"]` | 255は有効、256は不正 |
+| **複数解** | `"101023"` | 5解（例題参照） | 全分岐の網羅性 |
+| **不正文字** | `"12a34"` | `TypeError` | 数字以外を含む入力 |
**検証観点**：
+
- 残文字数の上下限枝刈りが正しく機能するか
- 先頭ゼロの処理（`max_len=1`）が正しいか
- 逐次数値化で255超過を正しく検出するか
@@ -303,25 +315,33 @@ class Solution:
FAQ
**Q1: なぜスライスを避けるのか？**
+
- A: `s[idx:idx+len]` は毎回新しい `str` オブジェクトを生成し、GC圧が高まる。キャッシュ参照なら既存オブジェクトの再利用で割り当てゼロ。
**Q2: `_SEG_CACHE` はどれくらいメモリを使うか？**
+
- A: 256個の文字列（`"0"`〜`"255"`）で合計約2KB程度。クラス変数として共有されるため、インスタンスごとの追加コストはゼロ。
**Q3: LeetCodeのMemoryスコアが100%にならない理由は？**
+
- A: 出力リスト自体のサイズが含まれるため、解の個数が多い入力では不可避に増加。中間オブジェクトは最小化済み。
**Q4: 先頭ゼロの処理が正しいか？**
+
- A: `first_is_zero` で先頭が `'0'` なら `max_len=1` に制限。`"01"` や `"001"` は試行されない。
**Q5: 枝刈りの効果は？**
+
- A: 残文字数の上下限チェックで、不可能な分岐（例：残り1文字で2セグメント必要）を即座に排除。実測で探索回数を大幅削減。
**Q6: 他のアプローチと比較すると？**
+
- A: 3重ループ（ドット位置総当り）は実装容易だが条件判定が散在。DFS + 枝刈りは制御フローが明確で高速。
**Q7: ジェネレータにできないか？**
+
- A: LeetCodeの関数シグネチャは `List[str]` 返却固定。プロダクションなら `yield` で逐次処理可能。
**Q8: 並列化は有効か？**
-- A: 探索空間が小さい（最大3^4）ため、GILのオーバーヘッドで逆に遅くなる。単一スレッドで十分。
\ No newline at end of file
+
+- A: 探索空間が小さい（最大3^4）ため、GILのオーバーヘッドで逆に遅くなる。単一スレッドで十分。
diff --git a/Algorithm/Backtracking/leetcode/93. Restore IP Addresses/GPT/README.md b/Algorithm/Backtracking/leetcode/93. Restore IP Addresses/GPT/README.md
index b423419a..b3c8cfdc 100644
--- a/Algorithm/Backtracking/leetcode/93. Restore IP Addresses/GPT/README.md
+++ b/Algorithm/Backtracking/leetcode/93. Restore IP Addresses/GPT/README.md
@@ -2,50 +2,49 @@
## Table of Contents
-* [概要](#overview)
-* [アルゴリズム要点（TL;DR）](#tldr)
-* [図解](#figures)
-* [正しさのスケッチ](#correctness)
-* [計算量](#complexity)
-* [Python 実装](#impl)
-* [CPython最適化ポイント](#cpython)
-* [エッジケースと検証観点](#edgecases)
-* [FAQ](#faq)
+- [概要](#overview)
+- [アルゴリズム要点（TL;DR）](#tldr)
+- [図解](#figures)
+- [正しさのスケッチ](#correctness)
+- [計算量](#complexity)
+- [Python 実装](#impl)
+- [CPython最適化ポイント](#cpython)
+- [エッジケースと検証観点](#edgecases)
+- [FAQ](#faq)
概要
-* **プラットフォーム/ID**: LeetCode 93
-* **タイトル**: Restore IP Addresses
-* **要約**: 数字のみの文字列 `s` に 3 個のドットを挿入して、**有効な IPv4 アドレス**（4 セグメント、各 0〜255、先頭ゼロ不可。ただし単独の "0" は可）を**すべて**列挙する。
-* **入出力仕様（簡潔）**
+- **プラットフォーム/ID**: LeetCode 93
+- **タイトル**: Restore IP Addresses
+- **要約**: 数字のみの文字列 `s` に 3 個のドットを挿入して、**有効な IPv4 アドレス**（4 セグメント、各 0〜255、先頭ゼロ不可。ただし単独の "0" は可）を**すべて**列挙する。
+- **入出力仕様（簡潔）**
+ - 入力: `s: str`（数字のみ、長さ 1〜20 だが有効解は 4〜12 桁に限定）
+ - 出力: `List[str]`（順不同の有効 IPv4 一覧）
- * 入力: `s: str`（数字のみ、長さ 1〜20 だが有効解は 4〜12 桁に限定）
- * 出力: `List[str]`（順不同の有効 IPv4 一覧）
-* **想定データ構造**: String
-* **代表例**
+- **想定データ構造**: String
+- **代表例**
+ - `s="25525511135"` → `["255.255.11.135","255.255.111.35"]`
+ - `s="0000"` → `["0.0.0.0"]`
+ - `s="101023"` → `["1.0.10.23","1.0.102.3","10.1.0.23","10.10.2.3","101.0.2.3"]`
- * `s="25525511135"` → `["255.255.11.135","255.255.111.35"]`
- * `s="0000"` → `["0.0.0.0"]`
- * `s="101023"` → `["1.0.10.23","1.0.102.3","10.1.0.23","10.10.2.3","101.0.2.3"]`
-* **関数シグネチャ（LeetCode準拠）**
-
- * `class Solution: def restoreIpAddresses(self, s: str) -> List[str]:`
+- **関数シグネチャ（LeetCode準拠）**
+ - `class Solution: def restoreIpAddresses(self, s: str) -> List[str]:`
アルゴリズム要点（TL;DR）
-* **戦略**: 深さ 4 の DFS でセグメント長を 1〜3 の範囲で試す。
-* **枝刈り**:
+- **戦略**: 深さ 4 の DFS でセグメント長を 1〜3 の範囲で試す。
+- **枝刈り**:
+ - 残文字数 `remainChars` と残セグメント数 `remainSegs` で **下限/上限**チェック：`remainSegs ≤ remainChars ≤ 3*remainSegs`
+ - 先頭 `'0'` は **長さ1のみ**許可（leading zero 禁止）。
+ - 数値が **255 を超えたら打ち切り**（以降の長い桁は必ず不適）。
- * 残文字数 `remainChars` と残セグメント数 `remainSegs` で **下限/上限**チェック：`remainSegs ≤ remainChars ≤ 3*remainSegs`
- * 先頭 `'0'` は **長さ1のみ**許可（leading zero 禁止）。
- * 数値が **255 を超えたら打ち切り**（以降の長い桁は必ず不適）。
-* **データ構造**: 一時バッファ `path[4]` を再利用して `'.'.join(path)` で完成。
-* **メモリ最適化**: `0..255` の文字列表現を **事前キャッシュ**して **部分文字列の slice を作らない**。
-* **計算量目標**: Time (O(1))（実質 3^4 分岐、n≤12） / Space (O(1))（出力除く）。
+- **データ構造**: 一時バッファ `path[4]` を再利用して `'.'.join(path)` で完成。
+- **メモリ最適化**: `0..255` の文字列表現を **事前キャッシュ**して **部分文字列の slice を作らない**。
+- **計算量目標**: Time (O(1))（実質 3^4 分岐、n≤12） / Space (O(1))（出力除く）。
-**フローチャート（探索と枝刈り）**
+## **フローチャート（探索と枝刈り）**
```mermaid
flowchart TD
@@ -72,9 +71,9 @@ flowchart TD
Recur3 --> Base
```
-*説明*: 深さ 4 の再帰で各セグメント長を試し、**残文字数の範囲**・**先頭ゼロ**・**255 超過**で枝刈りする。
+_説明_: 深さ 4 の再帰で各セグメント長を試し、**残文字数の範囲**・**先頭ゼロ**・**255 超過**で枝刈りする。
-**データフロー（前処理→DFS→出力）**
+## **データフロー（前処理→DFS→出力）**
```mermaid
graph LR
@@ -86,29 +85,29 @@ graph LR
F --> G[Return list]
```
-*説明*: 入力検証の後、固定配列 `path` と数値→文字列キャッシュで**中間オブジェクト生成を抑制**しながら列挙。
+_説明_: 入力検証の後、固定配列 `path` と数値→文字列キャッシュで**中間オブジェクト生成を抑制**しながら列挙。
正しさのスケッチ
-* **網羅性**: 各セグメントの長さを 1〜3 の全可能性について試すため、4 セグメント分の全挿入位置を漏れなく探索。
-* **有効性保持**:
+- **網羅性**: 各セグメントの長さを 1〜3 の全可能性について試すため、4 セグメント分の全挿入位置を漏れなく探索。
+- **有効性保持**:
+ - 先頭ゼロ規則（単独 "0" のみ）を満たすよう `max_len` を調整。
+ - 数値は逐次加算で評価し、255 を超えた時点で以降の長さは不可能なので打ち切り。
+ - 残文字数の範囲チェックにより、**必ず4セグメントを消費できる**構成のみ前進。
- * 先頭ゼロ規則（単独 "0" のみ）を満たすよう `max_len` を調整。
- * 数値は逐次加算で評価し、255 を超えた時点で以降の長さは不可能なので打ち切り。
- * 残文字数の範囲チェックにより、**必ず4セグメントを消費できる**構成のみ前進。
-* **基底条件**: `seg==4` のときに `idx==n` ならのみ解として採用。
-* **終了性**: 深さは最大 4、各段の分岐は最大 3、有限回で必ず終了。
+- **基底条件**: `seg==4` のときに `idx==n` ならのみ解として採用。
+- **終了性**: 深さは最大 4、各段の分岐は最大 3、有限回で必ず終了。
計算量
-* **Time**: (O(1))（n≤12、各段最大 3 分岐で高々 (3^4=81) 展開。出力サイズを除く）
-* **Space**: (O(1))（固定長 `path` のみ、結果配列を除く）
+- **Time**: (O(1))（n≤12、各段最大 3 分岐で高々 (3^4=81) 展開。出力サイズを除く）
+- **Space**: (O(1))（固定長 `path` のみ、結果配列を除く）
Python 実装
-> * LeetCode の関数シグネチャ準拠
-> * `from __future__ import annotations`・型注釈あり（pylance 対応）
-> * **Pure**（外部副作用なし）。`0..255` の文字列はクラスキャッシュで再利用
+> - LeetCode の関数シグネチャ準拠
+> - `from __future__ import annotations`・型注釈あり（pylance 対応）
+> - **Pure**（外部副作用なし）。`0..255` の文字列はクラスキャッシュで再利用
```python
from __future__ import annotations
@@ -194,28 +193,28 @@ class Solution:
CPython最適化ポイント
-* **slice 回避**: `s[idx:idx+len]` を作らず、`0..255` の文字列をクラスキャッシュから参照。
-* **逐次数値化**: `int()` ではなく `val = val*10 + (ord(ch)-48)` により、途中の短命オブジェクトを削減。
-* **ローカル束縛**: `SEG = self._SEG_CACHE`、`n = len(s)` などをローカルに保持して属性探索を減らす。
-* **固定長バッファ**: `path` は長さ 4 を再利用し、`'.'.join(path)` のみで最終文字列生成。
-* **再帰の浅さ**: 深さ最大 4 のため、関数呼び出しコストとスタック使用は極小。
+- **slice 回避**: `s[idx:idx+len]` を作らず、`0..255` の文字列をクラスキャッシュから参照。
+- **逐次数値化**: `int()` ではなく `val = val*10 + (ord(ch)-48)` により、途中の短命オブジェクトを削減。
+- **ローカル束縛**: `SEG = self._SEG_CACHE`、`n = len(s)` などをローカルに保持して属性探索を減らす。
+- **固定長バッファ**: `path` は長さ 4 を再利用し、`'.'.join(path)` のみで最終文字列生成。
+- **再帰の浅さ**: 深さ最大 4 のため、関数呼び出しコストとスタック使用は極小。
エッジケースと検証観点
-* **長さ外**: `len(s) < 4` または `> 12` は空リスト。
-* **全ゼロ**: `"0000"` → `"0.0.0.0"` のみ。
-* **先頭ゼロ混在**: `"010010"` → `"0.10.0.10","0.100.1.0"` など、先頭ゼロ規則が守られていること。
-* **上限値**: `"25525511135"` の代表解が含まれること。
-* **255超過の剪定**: `"256..."` のようなパスは早期に打ち切られること。
-* **非数字の防御**: 入力が数字以外を含む場合に `TypeError` が送出されること。
+- **長さ外**: `len(s) < 4` または `> 12` は空リスト。
+- **全ゼロ**: `"0000"` → `"0.0.0.0"` のみ。
+- **先頭ゼロ混在**: `"010010"` → `"0.10.0.10","0.100.1.0"` など、先頭ゼロ規則が守られていること。
+- **上限値**: `"25525511135"` の代表解が含まれること。
+- **255超過の剪定**: `"256..."` のようなパスは早期に打ち切られること。
+- **非数字の防御**: 入力が数字以外を含む場合に `TypeError` が送出されること。
FAQ
-* **Q. メモリ消費が気になります。もっと減らせますか？**
+- **Q. メモリ消費が気になります。もっと減らせますか？**
**A.** 出力リストは問題仕様上不可避ですが、上記実装は探索中の **部分文字列 slice を完全に排除**し、中間 `str` 生成を大幅に削減しています。これが CPython での実用的な最小化です。
-* **Q. 反復で書けますか？**
+- **Q. 反復で書けますか？**
**A.** 可能ですが、深さ 4 の軽量再帰は Python でも十分高速で読みやすいです。反復化のメリットは限定的です。
-* **Q. `parseInt` 相当の `int(s[i:j])` を使わない理由は？**
+- **Q. `parseInt` 相当の `int(s[i:j])` を使わない理由は？**
**A.** 毎回新しい `str` スライスが必要になりオーバーヘッドが増えます。逐次数値化はその生成を避けられます。
diff --git a/README.md b/README.md
index 0d340df9..25330e12 100644
--- a/README.md
+++ b/README.md
@@ -22,60 +22,61 @@
```mermaid
graph TB
Root[Algorithm-DataStructures-Math-SQL]
-
+
DS[DataStructures
データ構造]
Algo[Algorithm
アルゴリズム]
Math[Mathematics
数学]
SQL[SQL]
-
+
Root --> DS
Root --> Algo
Root --> Math
Root --> SQL
-
+
DS --> LinkedList[LinkedList
連結リスト]
DS --> Trees[Trees
木構造]
DS --> Arrays[Arrays
配列]
-
+
Algo --> BinarySearch[BinarySearch
二分探索]
Algo --> DP[DynamicProgramming
動的計画法]
Algo --> TwoPointer[TwoPointer
二つのポインタ]
-
+
Math --> FSM[FSM
有限状態機械]
Math --> Geometry[Geometry
幾何学]
Math --> GameTheory[GameTheory
ゲーム理論]
-
+
SQL --> LeetCodeSQL[Leetcode]
SQL --> HackerRankSQL[HackerRank]
```
-| 領域 | 代表的な関数/クラス | 主要パターン | ファイルの場所 |
-|------|---------------------|--------------|----------------|
-| **DataStructures** | `Solution.addTwoNumbers()`, `ListNode`, `DoublyLinkedList` | インプレース操作、ポインタ演算 | `DataStructures/LinkedList/`, `DataStructures/Trees/` |
-| **Algorithm** | `Solution.findMedianSortedArrays()`, `numDecodings()`, `minPathSum()` | 二分探索、動的計画法、二つのポインタ | `Algorithm/BinarySearch/`, `Algorithm/DynamicProgramming/` |
-| **Mathematics** | `isNumber()`, `reflectPoint()`, `gameWithCells()` | 状態機械、幾何変換 | `Mathematics/FSM/`, `Mathematics/Geometry/` |
-| **SQL** | `CombineTwoTables.sql`, `RisingTemperature.sql` | JOINパターン、ウィンドウ関数 | `SQL/Leetcode/`, `SQL/HackerRank/` |
+| 領域 | 代表的な関数/クラス | 主要パターン | ファイルの場所 |
+| ------------------ | --------------------------------------------------------------------- | ------------------------------------ | ---------------------------------------------------------- |
+| **DataStructures** | `Solution.addTwoNumbers()`, `ListNode`, `DoublyLinkedList` | インプレース操作、ポインタ演算 | `DataStructures/LinkedList/`, `DataStructures/Trees/` |
+| **Algorithm** | `Solution.findMedianSortedArrays()`, `numDecodings()`, `minPathSum()` | 二分探索、動的計画法、二つのポインタ | `Algorithm/BinarySearch/`, `Algorithm/DynamicProgramming/` |
+| **Mathematics** | `isNumber()`, `reflectPoint()`, `gameWithCells()` | 状態機械、幾何変換 | `Mathematics/FSM/`, `Mathematics/Geometry/` |
+| **SQL** | `CombineTwoTables.sql`, `RisingTemperature.sql` | JOINパターン、ウィンドウ関数 | `SQL/Leetcode/`, `SQL/HackerRank/` |
---
## デュアルAI実装戦略
-各問題は、**Claude**と**GPT**の両方のAIモデルから並列実装を受け、補完的なソリューションアプローチとコーディングスタイルを提供します。これにより、問題ごとに2×3実装マトリックス（2つのAIバリアント × 3つの言語）が作成されます。
+各問題は、**Claude**と**GPT**の両方のAIモデルから並列実装を受け、補完的なソリューションアプローチとコーディングスタイルを提供します。
+これにより、問題ごとに2×3実装マトリックス（2つのAIバリアント × 3つの言語）が作成されます。
```mermaid
graph LR
Problem[Problem
問題]
-
+
Claude[Claude実装]
GPT[GPT実装]
-
+
Problem --> Claude
Problem --> GPT
-
+
Claude --> CPython[Python
クラスベース]
Claude --> CTS[TypeScript
関数型]
Claude --> CJS[JavaScript
最適化版]
-
+
GPT --> GPython[Python
検証重視]
GPT --> GTS[TypeScript
型安全性]
GPT --> GJS[JavaScript
エラーハンドリング]
@@ -83,13 +84,13 @@ graph LR
### 実装比較
-| 側面 | Claude バリアント | GPT バリアント |
-|------|-------------------|----------------|
-| **Pythonクラスメソッド** | `findMedianSortedArrays(self, nums1: List[int], nums2: List[int]) -> float` | `_median_binary_partition(self, nums1: List[int], nums2: List[int]) -> float` |
-| **センチネル値** | `NEG: Final[int] = -10_000_007`
`POS: Final[int] = +10_000_007` | `INF: Final[float] = float("inf")` |
+| 側面 | Claude バリアント | GPT バリアント |
+| ------------------------ | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| **Pythonクラスメソッド** | `findMedianSortedArrays(self, nums1: List[int], nums2: List[int]) -> float` | `_median_binary_partition(self, nums1: List[int], nums2: List[int]) -> float` |
+| **センチネル値** | `NEG: Final[int] = -10_000_007`
`POS: Final[int] = +10_000_007` | `INF: Final[float] = float("inf")` |
| **TypeScriptシグネチャ** | `function findMedianSortedArrays(nums1: number[], nums2: number[]): number` | `function findMedianSortedArrays(nums1: readonly number[], nums2: readonly number[]): number` |
-| **最適化の焦点** | 整数センチネルによるfloatキャストの排除 | TypeError/RangeErrorによる包括的な入力検証 |
-| **ドキュメントスタイル** | 計算量優先＋最適化セクション | アルゴリズム比較表＋ビジネスコンテキスト |
+| **最適化の焦点** | 整数センチネルによるfloatキャストの排除 | TypeError/RangeErrorによる包括的な入力検証 |
+| **ドキュメントスタイル** | 計算量優先＋最適化セクション | アルゴリズム比較表＋ビジネスコンテキスト |
---
@@ -104,13 +105,13 @@ graph TB
PyTypes[typing.Final, List, Optional]
PyOpt[ord - 48, リスト内包表記
__slots__, ビットシフト]
end
-
+
subgraph TypeScript実装
TSFunc[function functionName]
TSTypes[readonly, strict types, Int32Array]
TSOpt[charCodeAt - 48, >>> 1
コンパイル時チェック]
end
-
+
subgraph JavaScript実装
JSFunc[function functionName]
JSTypes[動的型, ランタイム検証]
@@ -120,18 +121,18 @@ graph TB
### 言語別実装詳細
-| 言語 | クラス/関数パターン | 型システム | 主要な最適化 |
-|------|---------------------|------------|--------------|
-| **Python** | `class Solution:` with `def methodName(self, ...)` | `typing.Final`, `List[int]`, `Optional[T]` | `ord() - 48`, リスト内包表記, `__slots__`, ビットシフト `>> 1` |
-| **TypeScript** | `function functionName(...)` or `export function` | `readonly number[]`, strict types, `Int32Array` | `charCodeAt(0) - 48`, `>>> 1` (ゼロフィルシフト), コンパイル時チェック |
-| **JavaScript** | `function functionName(...)` or `var name = function(...)` | 動的型、ランタイム検証 | V8 Hidden Classes, `>> 1`, `Number.isFinite()`, シンプルなループ |
+| 言語 | クラス/関数パターン | 型システム | 主要な最適化 |
+| -------------- | ---------------------------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------- |
+| **Python** | `class Solution:` with `def methodName(self, ...)` | `typing.Final`, `List[int]`, `Optional[T]` | `ord() - 48`, リスト内包表記, `__slots__`, ビットシフト `>> 1` |
+| **TypeScript** | `function functionName(...)` or `export function` | `readonly number[]`, strict types, `Int32Array` | `charCodeAt(0) - 48`, `>>> 1` (ゼロフィルシフト), コンパイル時チェック |
+| **JavaScript** | `function functionName(...)` or `var name = function(...)` | 動的型、ランタイム検証 | V8 Hidden Classes, `>> 1`, `Number.isFinite()`, シンプルなループ |
### 言語別ビットシフト演算子
-| 演算 | Python | TypeScript | JavaScript | 目的 |
-|------|--------|------------|------------|------|
-| **算術右シフト** | `x >> 1` | `x >> 1` | `x >> 1` | 2で除算（符号保持） |
-| **ゼロフィル右シフト** | 利用不可 | `x >>> 1` | `x >>> 1` | 2で除算（符号なし） |
+| 演算 | Python | TypeScript | JavaScript | 目的 |
+| ---------------------- | -------- | ---------- | ---------- | ------------------- |
+| **算術右シフト** | `x >> 1` | `x >> 1` | `x >> 1` | 2で除算（符号保持） |
+| **ゼロフィル右シフト** | 利用不可 | `x >>> 1` | `x >>> 1` | 2で除算（符号なし） |
---
@@ -142,31 +143,31 @@ graph TB
```mermaid
graph LR
Platforms[プラットフォーム]
-
+
LC[LeetCode]
HR[HackerRank]
AC[AtCoder]
-
+
Platforms --> LC
Platforms --> HR
Platforms --> AC
-
+
LC --> LCAlgo[Algorithm/*/leetcode/]
LC --> LCSQL[SQL/Leetcode/]
-
+
HR --> HRMath[Mathematics/*/HackerRank/]
HR --> HRSQL[SQL/HackerRank/]
-
+
AC --> ACAlgo[Algorithm/*/AtCoder/]
```
### プラットフォーム別特性
-| プラットフォーム | 問題タイプ | 命名規則 | 制約フォーマット | ディレクトリ構造 |
-|------------------|------------|----------|------------------|------------------|
-| **LeetCode** | アルゴリズム、SQL、データ構造 | `{番号}. {タイトル}` | `0 <= m, n <= 1000`, `-10^6 <= nums[i] <= 10^6` | `Algorithm/*/leetcode/`, `SQL/Leetcode/` |
-| **HackerRank** | 数学、SQL、高度なアルゴリズム | `{カテゴリ}/{問題タイトル}` | ポイントベースの難易度、カスタム入力フォーマット | `Mathematics/*/HackerRank/`, `SQL/HackerRank/` |
-| **AtCoder** | 競技プログラミング | コンテストベースの命名 | 日本語＋英語ドキュメント | `Algorithm/*/AtCoder/` (存在する場合) |
+| プラットフォーム | 問題タイプ | 命名規則 | 制約フォーマット | ディレクトリ構造 |
+| ---------------- | ----------------------------- | --------------------------- | ------------------------------------------------ | ---------------------------------------------- |
+| **LeetCode** | アルゴリズム、SQL、データ構造 | `{番号}. {タイトル}` | `0 <= m, n <= 1000`, `-10^6 <= nums[i] <= 10^6` | `Algorithm/*/leetcode/`, `SQL/Leetcode/` |
+| **HackerRank** | 数学、SQL、高度なアルゴリズム | `{カテゴリ}/{問題タイトル}` | ポイントベースの難易度、カスタム入力フォーマット | `Mathematics/*/HackerRank/`, `SQL/HackerRank/` |
+| **AtCoder** | 競技プログラミング | コンテストベースの命名 | 日本語＋英語ドキュメント | `Algorithm/*/AtCoder/` (存在する場合) |
---
@@ -177,20 +178,20 @@ graph LR
```mermaid
graph TB
Problem[Problem Directory
問題ディレクトリ]
-
+
Claude[Claude/]
GPT[GPT/]
-
+
Problem --> Claude
Problem --> GPT
-
+
Claude --> CPy[*.py]
Claude --> CTS[*.ts]
Claude --> CJS[*.js]
Claude --> CMD[README.md]
Claude --> CHTML[README.html]
Claude --> CReact[README_react.html]
-
+
GPT --> GPy[*.py]
GPT --> GTS[*.ts]
GPT --> GJS[*.js]
@@ -201,18 +202,18 @@ graph TB
### ファイル命名規則
-| ファイルタイプ | 命名パターン | 目的 | 例 |
-|----------------|--------------|------|-----|
-| **Python実装** | `{ProblemName}.py` または `{problem_name}.py` | `class Solution`を含むコアアルゴリズム実装 | `Median_of_Two_Sorted_Arrays.py` |
-| **TypeScript実装** | `{ProblemName}.ts` | 厳密なチェックを伴う型安全な実装 | `Median_of_Two_Sorted_Arrays.ts` |
-| **JavaScript実装** | `{ProblemName}.js` | ランタイム検証済み実装 | `Median_of_Two_Sorted_Arrays.js` |
-| **静的ドキュメント** | `README.md` | 5段階のドキュメント構造 | `README.md` (セクションごと最大100行) |
-| **インタラクティブHTML** | `README.html` | Prism.jsシンタックスハイライト、Tailwind CSS | `README.html` (1000-2000行) |
-| **React可視化** | `README_react.html` | React 18 + Babel standalone、インタラクティブデモ | `README_react.html` |
+| ファイルタイプ | 命名パターン | 目的 | 例 |
+| ------------------------ | --------------------------------------------- | ------------------------------------------------- | ------------------------------------- |
+| **Python実装** | `{ProblemName}.py` または `{problem_name}.py` | `class Solution`を含むコアアルゴリズム実装 | `Median_of_Two_Sorted_Arrays.py` |
+| **TypeScript実装** | `{ProblemName}.ts` | 厳密なチェックを伴う型安全な実装 | `Median_of_Two_Sorted_Arrays.ts` |
+| **JavaScript実装** | `{ProblemName}.js` | ランタイム検証済み実装 | `Median_of_Two_Sorted_Arrays.js` |
+| **静的ドキュメント** | `README.md` | 5段階のドキュメント構造 | `README.md` (セクションごと最大100行) |
+| **インタラクティブHTML** | `README.html` | Prism.jsシンタックスハイライト、Tailwind CSS | `README.html` (1000-2000行) |
+| **React可視化** | `README_react.html` | React 18 + Babel standalone、インタラクティブデモ | `README_react.html` |
### SQL問題構造
-```
+```text
SQL/
├── Leetcode/
│ ├── Basic join/
@@ -232,16 +233,16 @@ SQL/
```mermaid
graph TB
Strategy[実装戦略]
-
+
Competitive[競技プログラミング版]
Production[プロダクション版]
-
+
Strategy --> Competitive
Strategy --> Production
-
+
Competitive --> CompFeatures[最小限の検証
最大実行速度
直接的なアルゴリズム実装]
Production --> ProdFeatures[包括的な入力検証
強化された型安全性
エラーハンドリング]
-
+
CompFeatures --> CompOpt[整数センチネル
ビットシフト >> 1
事前計算されたパリティチェック]
ProdFeatures --> ProdOpt[validateNumberArray
isNonDecreasing
TypeError/RangeError]
```
@@ -249,6 +250,7 @@ graph TB
### 競技プログラミングバリアント
**特徴:**
+
- 最小限の検証（問題の制約を信頼）
- 最大実行速度
- 直接的なアルゴリズム実装
@@ -256,6 +258,7 @@ graph TB
**例:** 整数センチネル（`NEG = -10_000_007`）を使用し、ホットパスでfloatキャストを排除
**最適化技術:**
+
- ビットシフト `>> 1`
- 事前計算されたパリティチェック `(total & 1) == 1`
- ローカル変数バインディング
@@ -263,24 +266,26 @@ graph TB
### プロダクションバリアント
**特徴:**
+
- 包括的な入力検証
- 強化された型安全性
- エラーハンドリングとエッジケース
**検証関数:**
+
- **Python:** `_validate_non_decreasing(arr: List[int]) -> bool`
- **TypeScript:** `validateNumberArray(arr: readonly number[]): void`
- **JavaScript:** `function validateArray(arr)` および `function isNonDecreasing(arr)`
### 最適化比較
-| 最適化 | 競技プログラミング版 | プロダクション版 |
-|--------|----------------------|------------------|
-| **入力検証** | スキップ（制約を信頼） | 違反時にTypeError、RangeError |
-| **センチネル値** | 整数センチネル: `-10_000_007`, `+10_000_007` | `float('inf')` または `±Infinity` |
-| **型チェック** | 最小限（型ヒントのみ） | ランタイム `Number.isFinite()`, `Array.isArray()` |
-| **エラーメッセージ** | なしまたは汎用的 | 説明的なメッセージを持つ特定のエラータイプ |
-| **エッジケース処理** | アルゴリズムを通じて暗黙的 | 早期リターンを伴う明示的な検証 |
+| 最適化 | 競技プログラミング版 | プロダクション版 |
+| -------------------- | -------------------------------------------- | ------------------------------------------------- |
+| **入力検証** | スキップ（制約を信頼） | 違反時にTypeError、RangeError |
+| **センチネル値** | 整数センチネル: `-10_000_007`, `+10_000_007` | `float('inf')` または `±Infinity` |
+| **型チェック** | 最小限（型ヒントのみ） | ランタイム `Number.isFinite()`, `Array.isArray()` |
+| **エラーメッセージ** | なしまたは汎用的 | 説明的なメッセージを持つ特定のエラータイプ |
+| **エッジケース処理** | アルゴリズムを通じて暗黙的 | 早期リターンを伴う明示的な検証 |
---
@@ -293,14 +298,14 @@ graph TB
```mermaid
graph LR
DevEnv[開発環境]
-
+
Python[Python 3.11.10]
Node[Node.js v18.x/v22.14.0]
Bun[Bun Lockfile v1]
TS[TypeScript]
ESLint[ESLint ^9.37.0]
LiveServer[live-server ^1.2.2]
-
+
DevEnv --> Python
DevEnv --> Node
DevEnv --> Bun
@@ -309,14 +314,14 @@ graph LR
DevEnv --> LiveServer
```
-| コンポーネント | バージョン/構成 | 目的 |
-|----------------|-----------------|------|
-| **Python** | CPython 3.11.10 | 型ヒント付きアルゴリズム実装 |
-| **Node.js** | v18.x (JavaScript), v22.14.0 (TypeScript) | TS/JS実装のランタイム |
-| **Bun** | Lockfile version 1 | パッケージ管理と決定論的ビルド |
-| **TypeScript** | @types/node ^22.18.10 | Node.jsの型定義 |
-| **ESLint** | ^9.37.0 | コード品質検証 |
-| **live-server** | ^1.2.2 | ライブリロード付き開発サーバー |
+| コンポーネント | バージョン/構成 | 目的 |
+| --------------- | ----------------------------------------- | ------------------------------ |
+| **Python** | CPython 3.11.10 | 型ヒント付きアルゴリズム実装 |
+| **Node.js** | v18.x (JavaScript), v22.14.0 (TypeScript) | TS/JS実装のランタイム |
+| **Bun** | Lockfile version 1 | パッケージ管理と決定論的ビルド |
+| **TypeScript** | @types/node ^22.18.10 | Node.jsの型定義 |
+| **ESLint** | ^9.37.0 | コード品質検証 |
+| **live-server** | ^1.2.2 | ライブリロード付き開発サーバー |
### Markdownlint設定詳細
@@ -339,21 +344,21 @@ graph LR
```mermaid
graph TB
UseCases[ユースケース]
-
+
Learning[アルゴリズム学習]
Competitive[競技プログラミング準備]
Interview[技術面接準備]
Optimization[パフォーマンス最適化]
Education[教育的価値]
MultiLang[多言語一貫性]
-
+
UseCases --> Learning
UseCases --> Competitive
UseCases --> Interview
UseCases --> Optimization
UseCases --> Education
UseCases --> MultiLang
-
+
Learning --> Comprehensive[包括的なリファレンス実装
計算量解析
ステップバイステップ可視化]
Competitive --> Optimized[最適化されたソリューション
最小限の検証
LeetCode/HackerRank/AtCoder対応]
Interview --> Patterns[実装パターン
ベストプラクティス
複数のソリューションアプローチ]
@@ -376,17 +381,17 @@ graph TB
```mermaid
graph LR
Audience[対象オーディエンス]
-
+
Beginner[初心者]
Intermediate[中級者]
Advanced[上級者]
Expert[エキスパート]
-
+
Audience --> Beginner
Audience --> Intermediate
Audience --> Advanced
Audience --> Expert
-
+
Beginner --> BeginnerContent[静的ドキュメント
基本的なアルゴリズム説明
計算量入門]
Intermediate --> IntermediateContent[インタラクティブHTML
ステップバイステップ実行
状態変化の観察]
Advanced --> AdvancedContent[React可視化
リアルタイム入力変更
エッジケーステスト]
@@ -396,15 +401,18 @@ graph LR
### 学習パスウェイ
**Tier 1（静的）:**
+
- 問題説明を読む
- アルゴリズム説明を理解する
- 計算量解析を学ぶ
**Tier 2（インタラクティブ）:**
+
- コントロール（Play/Pause/Next/Reset）でステップバイステップ実行
- 状態変化を観察
**Tier 3（React）:**
+
- リアルタイムで入力を変更
- エッジケースをテスト
- AI実装を比較
@@ -415,7 +423,6 @@ graph LR
本リポジトリは、教育、競技プログラミング、技術面接準備のための包括的なプラットフォームを提供します。デュアルAI実装戦略、多言語サポート、3層ドキュメントシステムにより、初心者からエキスパートまで、あらゆるレベルの学習者に対応しています。
-
**⭐ このプロジェクトが役立ちましたら、ぜひスターを付けてください！**