Merge Variant Gallery into main chapters: TSP top-down functional into 17.4, LRU linked-list family into 18.1, coin/BFS/counting into 2.16, N-Queens set-based into 12.4, Eulerian trio into 17.9, WL2 forward-BFS into 6.13, LFU lean into 18.2, TreeSet median into 7.3, Kahn filter-seed into 6.3/6.8, functional/map-key/structure sections into their chapters; delete ch19-gallery; add proper pages 8.10 Basic Calculator II, 10.12 Rank Transform, 10.13 Unique Occurrences, 16.8 Pow(x,n)

Author: arpanpathak

CodingInterviewFightClub/src/SUMMARY.md

@@ -133,6 +133,7 @@
   - [8.7 Remove K Digits](ch08-stacks/remove-k-digits.md)
   - [8.8 Decode String](ch08-stacks/decode-string.md)
   - [8.9 Longest Valid Parentheses](ch08-stacks/longest-valid-parentheses.md)
+  - [8.10 Basic Calculator II](ch08-stacks/basic-calculator-ii.md)
 
 - [9. Strings](ch09-strings/index.md)
   - [9.0 Pattern Primer: The Three Lenses](ch09-strings/pattern-primer.md)
@@ -161,6 +162,8 @@
   - [10.9 Count Rectangles Formed By Points](ch10-hash-tables/count-rectangles-formed-by-points.md)
   - [10.10 First Missing Positive](ch10-hash-tables/first-missing-positive.md)
   - [10.11 Subarray Sums Divisible By K](ch10-hash-tables/subarray-sums-divisible-by-k.md)
+  - [10.12 Rank Transform Of An Array](ch10-hash-tables/rank-transform-of-an-array.md)
+  - [10.13 Unique Number Of Occurrences](ch10-hash-tables/unique-number-of-occurrences.md)
 
 - [11. Greedy](ch11-greedy/index.md)
   - [11.0 Pattern Primer: The Local Choice, Defended](ch11-greedy/pattern-primer.md)
@@ -231,6 +234,7 @@
   - [16.5 Maximum XOR Of Two Numbers](ch16-bit-manipulation/maximum-xor-of-two-numbers.md)
   - [16.6 Sum Of All Subset XOR Totals](ch16-bit-manipulation/sum-of-all-subset-xor-totals.md)
   - [16.7 Smallest Number With All Set Bits](ch16-bit-manipulation/smallest-number-with-all-set-bits.md)
+  - [16.8 Pow(x, n)](ch16-bit-manipulation/pow-x-n.md)
 
 - [17. Advanced Graphs](ch17-advanced-graphs/index.md)
   - [17.0 Pattern Primer: Flow, Matching, MST, and State-Space BFS](ch17-advanced-graphs/pattern-primer.md)
@@ -263,19 +267,3 @@
 - [Repo Coverage Index](appendix-repo-coverage-index.md) — every file in src/main/kotlin mapped
 - [The Roadmap](appendix-roadmap.md) — the remaining uncovered files
 
-- [Chapter 19 — Variant Gallery](ch19-gallery/index.md)
-  - [19.0 Pattern Primer: Same Algorithm, Different Costumes](ch19-gallery/pattern-primer.md)
-  - [19.1 Travelling Salesman — Top-Down Functional](ch19-gallery/travelling-salesman-top-down.md)
-  - [19.2 LRU Cache — Linked-List Family](ch19-gallery/lru-cache-linked-list-family.md)
-  - [19.3 Coin Change — Four Implementations](ch19-gallery/coin-change-family.md)
-  - [19.4 N-Queens — Set-Based Family](ch19-gallery/n-queen-family.md)
-  - [19.5 The Shorter/Better Gallery](ch19-gallery/short-code-gallery.md)
-  - [19.6 The Eulerian Family](ch19-gallery/eulerian-family.md)
-  - [19.7 The Functional-Programming Gallery](ch19-gallery/functional-programming-gallery.md)
-  - [19.8 Word Ladder II — Three Implementations](ch19-gallery/word-ladder-ii-family.md)
-  - [19.9 LFU Cache — Three Implementations](ch19-gallery/lfu-cache-family.md)
-  - [19.10 Sliding Window Median — TreeSet](ch19-gallery/sliding-window-median-treeset.md)
-  - [19.11 Kahn's Filter-Seed & DFS-Expression](ch19-gallery/kahns-filter-seed.md)
-  - [19.12 One-Expression DP Gallery](ch19-gallery/one-expression-dp-gallery.md)
-  - [19.13 Map-Key Gallery](ch19-gallery/map-key-gallery.md)
-  - [19.14 Structure Gallery](ch19-gallery/structure-gallery.md)

CodingInterviewFightClub/src/ch01-binary-search/find-peak-element.md

@@ -140,6 +140,38 @@ impl Solution {
 }
 ```
 
+### 4. `FindPeakElementBetterSolution.kt` — boundary-safe peak
+
+[1.6](../ch01-binary-search/find-peak-element.md) documents the standard binary-search peak; this file's "better" claim is **explicit boundary handling** — neighbors default to `Int.MIN_VALUE` at the edges:
+
+```kotlin
+class FindPeakElementBetterSolution {
+    fun findPeakElement(nums: IntArray): Int? {
+        if (nums.isEmpty()) return null
+
+        var (left, right) = 0 to nums.size - 1
+
+        while (left < right) {
+            val mid = left + (right - left) / 2
+
+            // Safely handle boundaries
+            val leftNeighbor = if (mid > 0) nums[mid - 1] else Int.MIN_VALUE
+            val rightNeighbor = if (mid < nums.size - 1) nums[mid + 1] else Int.MIN_VALUE
+
+            when {
+                nums[mid] > leftNeighbor && nums[mid] > rightNeighbor -> return mid   // peak
+                nums[mid] < rightNeighbor -> left = mid + 1                            // go right
+                else -> right = mid                                                    // go left
+            }
+        }
+        return left
+    }
+}
+```
+
+**What's cool:** the `Int.MIN_VALUE` neighbors make the boundary cells valid peaks (a single-element array's only element is a peak); the `when` reads as the three-way decision; and `Int?` return explicitly signals "empty input". The three-branch structure also avoids [1.7](../ch01-binary-search/find-peak-element-safe.md)'s separate "safe boundaries" page — this file *is* that page's idea in one method.
+
+
 ## Dry run
 
 **Input:** `nums = [1, 2, 3, 1]`

CodingInterviewFightClub/src/ch02-dynamic-programming/coin-change.md

@@ -147,6 +147,118 @@ impl Solution {
 }
 ```
 
+> **Sources:** [`src/main/kotlin/array/dp/`](https://github.com/arpanpathak/AdvancedAlgorithmPatterns/tree/main/src/main/kotlin/array/dp) — `CoinChange.kt`, `CoinChangeBottomUp.kt`, `CoinChangeBFS.kt`, `CoinChange_II.kt`, `CoinChange_II_BottomUp.kt`
+> **Pattern:** variant gallery — one problem, four engines ([2.16](../ch02-dynamic-programming/coin-change.md) covers the bottom-up winner)
+
+### The family map
+
+| File | Engine | What it proves |
+|---|---|---|
+| `CoinChange.kt` | memoized top-down + `coinChangeCleanAf` bottom-up | both spellings, one file |
+| `CoinChangeBottomUp.kt` | bottom-up + a functional `forEach` flavor | the table fill in filter-min style |
+| `CoinChangeBFS.kt` | **BFS over amounts** | "fewest coins" is a shortest-path problem |
+| `CoinChange_II.kt` / `_BottomUp.kt` | ways-counting DP | the *counting* twin ([2.16](../ch02-dynamic-programming/coin-change.md) variants) |
+
+### The BFS surprise: `CoinChangeBFS.kt`
+
+The coolest of the four: "fewest coins to reach `amount`" is exactly "shortest path from `0` to `amount` in a graph where each coin is an edge `x → x + coin`". BFS finds it in `O(amount · coins)`:
+
+```kotlin
+fun coinChangeBFS(coins: IntArray, amount: Int): Int {
+    if (amount == 0) return 0
+
+    val queue = ArrayDeque<Int>().apply { add(0) }
+    val visited = mutableSetOf(0)
+    var steps = 0
+
+    while (queue.isNotEmpty()) {
+        steps++
+        repeat(queue.size) {                  // one level = one coin
+            val current = queue.removeFirst()
+            for (coin in coins) {
+                val next = current + coin
+                if (next == amount) return steps
+                if (next < amount && visited.add(next)) {
+                    queue.add(next)
+                }
+            }
+        }
+    }
+    return -1
+}
+```
+
+**Why it's correct:** every path from 0 to `amount` uses `k` edges = `k` coins, and BFS finds the minimum hop count. **Why `visited`?** Amounts are re-reachable many ways (`0+1+1` vs `0+2`); the first visit is the fewest coins, so revisits are pruned — same as [6.14](../ch06-graphs/rotting-oranges.md)'s `fresh == INF` guard. The `steps` counter with `repeat(queue.size)` is the [5.2](../ch05-trees/binary-tree-level-order-traversal.md) level fence.
+
+**When to reach for it in an interview:** when the problem is *phrased* as reachability ("can you make the amount? what's the minimum number of coins?") — the graph framing is a different intuition that some interviewers love, and it pairs beautifully with the DP as "two views of the same recurrence".
+
+### The counting twin: `CoinChange_II.kt`
+
+"Number of ways" flips the recurrence from `min` to `sum`, and the **loop order matters** — coins outer, amounts inner makes each combination counted once:
+
+```kotlin
+// CoinChange_II.kt (bottom-up counting)
+fun change(amount: Int, coins: IntArray): Int {
+    val dp = IntArray(amount + 1)
+    dp[0] = 1                                    // one way to make 0: take nothing
+
+    for (coin in coins) {                        // coin loop OUTSIDE
+        for (a in coin..amount) {
+            dp[a] += dp[a - coin]                // order matters: combinations, not permutations
+        }
+    }
+    return dp[amount]
+}
+```
+
+The coin-outer loop is the classic "count combinations vs permutations" distinction ([2.6](../ch02-dynamic-programming/partition-equal-subset-sum.md)'s ascending-vs-descending discussion is this exact subtlety). `dp[0] = 1` seeds the empty combination.
+
+### The top-down in the same file: `CoinChange.kt`
+
+```kotlin
+class CoinChange {
+    fun coinChange(coins: IntArray, amount: Int): Int {
+        val dp = IntArray(amount + 1) { -1 }
+        return coinChange(coins, amount, dp).let { if (it != Int.MAX_VALUE) it else -1 }
+    }
+
+    private fun coinChange(coins: IntArray, amount: Int, dp: IntArray): Int {
+        return when {
+            amount == 0 -> 0
+            dp[amount] != -1 -> dp[amount]
+            else -> {
+                var minCoins = Int.MAX_VALUE
+                for (coin in coins) {
+                    if (coin <= amount) {
+                        val result = coinChange(coins, amount - coin, dp)
+                        if (result != Int.MAX_VALUE) {
+                            minCoins = minOf(minCoins, 1 + result)
+                        }
+                    }
+                }
+                minCoins
+            }
+        }.also { dp[amount] = it }
+    }
+}
+```
+
+The `Int.MAX_VALUE` sentinel marks "unreachable"; the `.also { dp[amount] = it }` memoizes on every return path (including the base cases — harmless). The `-1` sentinel in the public wrapper distinguishes "impossible" from "0 coins".
+
+### Dry run (BFS)
+
+**Input:** `coins = [1,2,5]`, `amount = 11`.
+
+```
+queue=[0], visited={0}, steps=0
+steps=1: 0 -> 1, 2, 5.  queue=[1,2,5]
+steps=2: 1 -> 2(seen),3,6.  2 -> 3(seen),4,7.  5 -> 6(seen),7(seen),10.  queue=[3,6,4,7,10]
+steps=3: 3 -> 4(seen),5(seen),8.  6 -> 7(seen),8(seen),11 == amount -> return 3 ✓
+```
+
+BFS finds 11 at depth 3 (5+5+1) — the `visited` set keeps the frontier small (amounts reached cheaply are never re-expanded). The DP and BFS agree: fewest coins = 3.
+
+
 ## Dry run
 
 **Input:** `coins = [1,2,5]`, `amount = 11`.

CodingInterviewFightClub/src/ch02-dynamic-programming/frog-jump.md

@@ -209,6 +209,43 @@ impl Solution {
 }
 ```
 
+### 1. `FrogJumpTopDown.kt` — the whole DP in a `getOrPut` + `any`
+
+[2.8](../ch02-dynamic-programming/frog-jump.md) documents the canonical version (set of reachable jumps per stone). This file compresses it to a two-line recurrence:
+
+```kotlin
+class FrogJumpTopDown {
+    data class State(val pos: Int, val k: Int)
+
+    fun canCross(stones: IntArray): Boolean {
+        val stoneSet = stones.toSet()
+        val cache = mutableMapOf<State, Boolean>()
+
+        fun isValidJump(pos: Int, nextJump: Int) =
+            nextJump > 0 && (pos + nextJump) in stoneSet
+
+        fun solve(pos: Int, k: Int): Boolean =
+            cache.getOrPut(State(pos, k)) {
+                pos == stones.last() || (k - 1..k + 1).any { nextJump ->
+                    isValidJump(pos, nextJump) && solve(pos + nextJump, nextJump)
+                }
+            }
+
+        return solve(0, 0)
+    }
+}
+```
+
+**What's cool:**
+
+- **`(k - 1..k + 1).any { ... }`** — the three candidate jump lengths (`k-1, k, k+1`) are a *range expression*, not a loop. `any` short-circuits on the first successful jump.
+- **`isValidJump` as a named lambda-expression** — `nextJump > 0 && (pos + nextJump) in stoneSet`; the stone-set membership IS the boundary check (no bounds arithmetic).
+- **`pos == stones.last()`** — the base case is a boolean OR'd into the recurrence, not a separate branch.
+- **`data class State`** — `(pos, k)` hashed by the map; the [17.4](../ch17-advanced-graphs/travelling-salesman-held-karp.md) state-value idiom.
+
+The imperative version's two loops (outer stones, inner jumps) are gone — the recurrence is the whole file.
+
+
 ## Dry run
 
 **Input:** `stones = [0, 1, 3, 5, 6, 8, 12, 17]`. Bottom-up propagation:

CodingInterviewFightClub/src/ch02-dynamic-programming/maximal-square.md

@@ -168,6 +168,37 @@ impl Solution {
 }
 ```
 
+### 2. `MaximalRectangle.kt` — the histogram-stack upgrade
+
+The classic "largest rectangle in a binary matrix" via **per-row histograms + the [8.5](../ch08-stacks/largest-rectangle-in-histogram.md) stack**:
+
+```kotlin
+class MaximalRectangle {
+    fun largestRectangleArea(heights: IntArray): Int {
+        val stack = Stack<Int>()
+        var (maxArea, i) = listOf(0, 0)
+
+        while (i <= heights.size) {
+            val currentHeight = if (i == heights.size) 0 else heights[i]   // sentinel 0 flushes
+
+            when {
+                stack.isEmpty() || heights[stack.last()] <= currentHeight -> stack.add(i++)
+                else -> {
+                    val height = heights[stack.pop()]
+                    val width = if (stack.isEmpty()) i else i - stack.peek() - 1
+                    maxArea = maxOf(maxArea, height * width)
+                }
+            }
+        }
+        return maxArea
+    }
+    // ... plus the per-row histogram accumulation: heights[j] = if (matrix[i][j] == '1') heights[j] + 1 else 0
+}
+```
+
+**What's cool:** the `i == heights.size ? 0` sentinel flushes the stack without a post-loop; the `when` is the monotonic-stack three-way decision ([8.5](../ch08-stacks/largest-rectangle-in-histogram.md) compressed); and the row-major histogram update turns the matrix problem into repeated 1-D problems.
+
+
 ## Dry run
 
 **Input:** `matrix = [["1","1"],["1","1"]]`.

CodingInterviewFightClub/src/ch02-dynamic-programming/minimum-cost-to-cut-a-stick.md

@@ -232,6 +232,39 @@ impl Solution {
 }
 ```
 
+### 2. `StoneGame.kt` — the zero-sum relative score
+
+The "Current Player's Score − Opponent's Score" trick lets the DP avoid tracking turns:
+
+```kotlin
+fun stoneGame(piles: IntArray): Boolean {
+    // Cache stores (i to j) -> Max relative score difference for that range
+    val cache = mutableMapOf<Pair<Int, Int>, Int>()
+
+    /**
+     * Returns (Current Player's Score - Opponent's Score) for the range [i, j].
+     * This "Relative Score" approach avoids needing to track whose turn it is.
+     */
+    fun pick(i: Int, j: Int): Int = cache.getOrPut(i to j) {
+        when (i) {
+            j -> piles[i]                        // one pile left: take it all
+
+            // Subtract the opponent's result: the recursive call returns the
+            // advantage for the NEXT player.
+            else -> maxOf(
+                piles[i] - pick(i + 1, j),       // take left, subtract opponent's net gain
+                piles[j] - pick(i, j - 1)        // take right, subtract opponent's net gain
+            )
+        }
+    }
+
+    return pick(0, piles.lastIndex) >= 0
+}
+```
+
+**What's cool:** `piles[i] - pick(i+1, j)` — the *relative* score means the recursion never asks "whose turn?"; the sign flips encode it. The `when (i) { j -> ... }` base case is the single-pile boundary. This is the [2.x](../ch02-dynamic-programming/pattern-primer.md) interval-DP family ([2.10](../ch02-dynamic-programming/minimum-cost-to-cut-a-stick.md) style) with the zero-sum trick as the differentiator.
+
+
 ## Dry run
 
 **Input:** `n = 7`, `cuts = [1, 3, 4, 5]` → `points = [0, 1, 3, 4, 5, 7]`.

CodingInterviewFightClub/src/ch05-trees/binary-tree-level-order-traversal.md

@@ -183,6 +183,36 @@ impl Solution {
 }
 ```
 
+### 3. `BinaryTreeVerticalOrderTraversal.kt` — the `data class` BFS state
+
+The vertical-order BFS carries `(node, column)` — and the repo even shows the *functional DFS sketch* commented out, with `TreeMap` + `getOrPut`:
+
+```kotlin
+// The commented-out functional DFS (the "what if" sketch):
+//   fun dfs(node: TreeNode?, verticalIndex: Int = 0) {
+//       if (node == null) return
+//       val bucket = result.getOrPut(verticalIndex) { LinkedList() }
+//       bucket.add(node.`val`)
+//       dfs(node.left, verticalIndex - 1)
+//       dfs(node.right, verticalIndex + 1)
+//   }
+//   return result.map { it.value }
+
+// The BFS version uses an explicit state carrier:
+data class VerticalIndex(val node: TreeNode, val verticalIndex: Int)
+
+fun verticalOrder(root: TreeNode?): List<List<Int>> {
+    if (root == null) return emptyList()
+    val result = TreeMap<Int, ArrayList<Int>>()
+    val queue: Queue<VerticalIndex> = LinkedList()
+    queue.offer(VerticalIndex(root, 0))
+    // ... BFS with (node, column) pairs; TreeMap keeps columns sorted
+}
+```
+
+**What's cool:** the commented DFS is the *teaching artifact* — it shows the natural (but order-incorrect) recursion before the BFS that fixes level order; `getOrPut(verticalIndex) { LinkedList() }` is the bucket-create idiom; and the `data class` state carrier is the [6.x](../ch06-graphs/pattern-primer.md) "BFS with payload" pattern.
+
+
 ## Dry run
 
 **Input:** the tree above.