7a:T422,Before diving into specific bug patterns, we must understand what makes algorithmic debugging uniquely challenging. This understanding shapes our entire approach. **The Silent Failure Problem** Consider the difference between these two types of bugs: 1. **Crash bug:** You call `array[index]` with an invalid index. The program crashes with an explicit error message pointing to the exact line. 2. **Logic bug:** Your binary search returns index 5 when the correct answer is index 6. The program runs perfectly, produces output, and you have no indication anything is wrong—until you check against expected results. Algorithmic bugs are overwhelmingly of the second type. There's no error message. The algorithm simply produces the wrong answer, and the wrongness can be: - **Subtly wrong:** Correct for most inputs, wrong for edge cases - **Off by a constant:** Always one more or less than expected - **Wrong for large inputs:** Correct for small test cases, fails at scale - **Non-deterministically wrong:** Fails only under specific input patterns7b:T6d1,# BUGGY: Classic off-by-one in binary search def binary_search_buggy(arr, target): left, right = 0, len(arr) # BUG: should be len(arr) - 1 for inclusive while left < right: # BUG: should check left <= right for inclusive bounds mid = (left + right) // 2 if arr[mid] == target: return mid elif arr[mid] < target: left = mid + 1 else: right = mid - 1 # BUG: inconsistent with initial right = len(arr) return -1 # CORRECT: Consistent inclusive bounds def binary_search_correct(arr, target): if not arr: # Handle empty array - boundary case! return -1 left, right = 0, len(arr) - 1 # CORRECT: inclusive on both ends while left <= right: # CORRECT: includes the case where left == right mid = (left + right) // 2 if arr[mid] == target: return mid elif arr[mid] < target: left = mid + 1 else: right = mid - 1 # CORRECT: consistent with inclusive bounds return -1 # BUGGY: Wrong loop bounds in prefix sum def prefix_sum_buggy(arr): n = len(arr) prefix = [0] * n # BUG: n+1 needed for 0-indexed prefix sums for i in range(n): prefix[i] = prefix[i-1] + arr[i] # BUG: prefix[-1] on first iteration! return prefix # CORRECT: Proper prefix sum with correct bounds def prefix_sum_correct(arr): n = len(arr) prefix = [0] * (n + 1) # CORRECT: extra element for "empty prefix" for i in range(n): prefix[i + 1] = prefix[i] + arr[i] # CORRECT: 1-indexed prefix return prefix # prefix[0] = 0 (sum of zero elements) # prefix[1] = arr[0] # prefix[k] = sum of first k elements7c:T7b8,// BUGGY: Classic off-by-one in binary search function binarySearchBuggy(arr: number[], target: number): number { let left = 0; let right = arr.length; // BUG: should be arr.length - 1 for inclusive while (left < right) { // BUG: should check left <= right for inclusive bounds const mid = Math.floor((left + right) / 2); if (arr[mid] === target) { return mid; } else if (arr[mid] < target) { left = mid + 1; } else { right = mid - 1; // BUG: inconsistent with initial right = len(arr) } } return -1; } // CORRECT: Consistent inclusive bounds function binarySearchCorrect(arr: number[], target: number): number { if (arr.length === 0) { // Handle empty array - boundary case! return -1; } let left = 0; let right = arr.length - 1; // CORRECT: inclusive on both ends while (left <= right) { // CORRECT: includes the case where left == right const mid = Math.floor((left + right) / 2); if (arr[mid] === target) { return mid; } else if (arr[mid] < target) { left = mid + 1; } else { right = mid - 1; // CORRECT: consistent with inclusive bounds } } return -1; } // BUGGY: Wrong loop bounds in prefix sum function prefixSumBuggy(arr: number[]): number[] { const n = arr.length; const prefix = new Array(n).fill(0); // BUG: n+1 needed for (let i = 0; i < n; i++) { prefix[i] = prefix[i - 1] + arr[i]; // BUG: prefix[-1] is undefined! } return prefix; } // CORRECT: Proper prefix sum with correct bounds function prefixSumCorrect(arr: number[]): number[] { const n = arr.length; const prefix = new Array(n + 1).fill(0); // CORRECT: extra element for (let i = 0; i < n; i++) { prefix[i + 1] = prefix[i] + arr[i]; // CORRECT: 1-indexed prefix } return prefix; }7d:Tbb7,# BUGGY: Wrong initialization for maximum subarray def max_subarray_buggy(nums): max_sum = 0 # BUG: What if all numbers are negative? current_sum = 0 for num in nums: current_sum = max(num, current_sum + num) max_sum = max(max_sum, current_sum) return max_sum # Returns 0 for [-5, -3, -1], should return -1 # CORRECT: Initialize with first element def max_subarray_correct(nums): if not nums: return 0 # Or raise an error - define behavior for empty input! max_sum = nums[0] # CORRECT: Start with first element current_sum = nums[0] for i in range(1, len(nums)): # Start from index 1 current_sum = max(nums[i], current_sum + nums[i]) max_sum = max(max_sum, current_sum) return max_sum # Returns -1 for [-5, -3, -1], correctly! # BUGGY: DP initialization error def unique_paths_buggy(m: int, n: int) -> int: """Count unique paths from top-left to bottom-right in an m×n grid.""" dp = [[0] * n for _ in range(m)] # BUG: Forgot to initialize first row and column! # Without initialization, dp[0][0] = 0, so everything stays 0. for i in range(m): for j in range(n): dp[i][j] = dp[i-1][j] + dp[i][j-1] # Also buggy for i=0 or j=0 return dp[m-1][n-1] # Returns 0 always! # CORRECT: Proper DP initialization def unique_paths_correct(m: int, n: int) -> int: dp = [[0] * n for _ in range(m)] # Initialize: only one way to reach any cell in first row or column for i in range(m): dp[i][0] = 1 # CORRECT: First column for j in range(n): dp[0][j] = 1 # CORRECT: First row # Fill rest of the table for i in range(1, m): for j in range(1, n): dp[i][j] = dp[i-1][j] + dp[i][j-1] return dp[m-1][n-1] # BUGGY: Graph initialization error from collections import deque def bfs_shortest_path_buggy(graph, start, end): """Find shortest path length from start to end.""" queue = deque([(start, 0)]) # BUG: Forgot to initialize visited set with start! visited = set() while queue: node, dist = queue.popleft() if node == end: return dist for neighbor in graph[node]: if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, dist + 1)) return -1 # BUG: start might be visited multiple times from different paths # CORRECT: Initialize visited with start node def bfs_shortest_path_correct(graph, start, end): queue = deque([(start, 0)]) visited = {start} # CORRECT: Mark start as visited immediately while queue: node, dist = queue.popleft() if node == end: return dist for neighbor in graph[node]: if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, dist + 1)) return -17e:Tb8f,# BUGGY: Order of update error in DP def house_robber_buggy(nums): """Maximum sum skipping adjacent elements.""" if not nums: return 0 if len(nums) == 1: return nums[0] prev_prev = nums[0] # Maximum sum ending at i-2 prev = max(nums[0], nums[1]) # Maximum sum ending at i-1 for i in range(2, len(nums)): # BUG: Update prev before using it to calculate current! prev = max(prev, prev_prev + nums[i]) # Uses wrong prev! prev_prev = prev # Now prev_prev = current, not the old prev return prev # Wrong answer due to order bug # CORRECT: Use temporary variable for correct order def house_robber_correct(nums): if not nums: return 0 if len(nums) == 1: return nums[0] prev_prev = nums[0] prev = max(nums[0], nums[1]) for i in range(2, len(nums)): current = max(prev, prev_prev + nums[i]) # CORRECT: compute first prev_prev = prev # CORRECT: shift window prev = current return prev # BUGGY: In-place modification while iterating def remove_duplicates_buggy(nums): """Remove duplicates from sorted array in-place.""" for i, num in enumerate(nums): # BUG: Modifying nums while iterating causes chaos if i > 0 and num == nums[i-1]: nums.pop(i) # Shifts remaining elements, indices now wrong! return len(nums) # CORRECT: Two-pointer approach for in-place modification def remove_duplicates_correct(nums): if len(nums) <= 1: return len(nums) write_idx = 1 # Where to write the next unique element for read_idx in range(1, len(nums)): if nums[read_idx] != nums[read_idx - 1]: nums[write_idx] = nums[read_idx] write_idx += 1 return write_idx # Length of the unique portion # BUGGY: Reference mutation in backtracking def permutations_buggy(nums): result = [] def backtrack(current, remaining): if not remaining: result.append(current) # BUG: Appends reference, not copy! return for i, num in enumerate(remaining): current.append(num) # Mutate current backtrack(current, remaining[:i] + remaining[i+1:]) current.pop() # Restore current backtrack([], nums) return result # All elements are empty lists! # CORRECT: Append a copy, not the reference def permutations_correct(nums): result = [] def backtrack(current, remaining): if not remaining: result.append(current.copy()) # CORRECT: Append a copy! # Or: result.append(current[:]) # Or: result.append(list(current)) return for i, num in enumerate(remaining): current.append(num) backtrack(current, remaining[:i] + remaining[i+1:]) current.pop() backtrack([], nums) return result7f:Tf76,# BUGGY: Wrong recurrence for coin change def coin_change_buggy(coins, amount): """Minimum coins to make amount.""" memo = {} def dp(remaining): if remaining == 0: return 0 if remaining < 0: return float('inf') if remaining in memo: return memo[remaining] # BUG: Recurrence is wrong - we're not finding MINIMUM result = 0 for coin in coins: result += dp(remaining - coin) # BUG: Adding instead of min! memo[remaining] = result return result result = dp(amount) return result if result != float('inf') else -1 # CORRECT: Proper minimum recurrence def coin_change_correct(coins, amount): memo = {} def dp(remaining): if remaining == 0: return 0 if remaining < 0: return float('inf') if remaining in memo: return memo[remaining] result = float('inf') # CORRECT: Start with infinity for coin in coins: # CORRECT: Take minimum of all choices result = min(result, 1 + dp(remaining - coin)) memo[remaining] = result return result result = dp(amount) return result if result != float('inf') else -1 # BUGGY: Incomplete memoization key def longest_common_subsequence_buggy(text1, text2): """LCS with buggy memoization.""" memo = {} def dp(i, j): if i == len(text1) or j == len(text2): return 0 # BUG: Only using 'i' as key, ignoring 'j'! if i in memo: # Wrong key - collides for different j values return memo[i] if text1[i] == text2[j]: result = 1 + dp(i + 1, j + 1) else: result = max(dp(i + 1, j), dp(i, j + 1)) memo[i] = result return result return dp(0, 0) # CORRECT: Full state in memoization key def longest_common_subsequence_correct(text1, text2): memo = {} def dp(i, j): if i == len(text1) or j == len(text2): return 0 # CORRECT: Use tuple (i, j) as key if (i, j) in memo: return memo[(i, j)] if text1[i] == text2[j]: result = 1 + dp(i + 1, j + 1) else: result = max(dp(i + 1, j), dp(i, j + 1)) memo[(i, j)] = result return result return dp(0, 0) # BUGGY: Missing state in subproblem definition def can_partition_to_equal_sum_buggy(nums): """Check if array can be partitioned into two equal-sum subsets.""" total = sum(nums) if total % 2 != 0: return False target = total // 2 memo = {} def dp(i, current_sum): if current_sum == target: return True if i >= len(nums): return False # BUG: Only memoizing on current_sum, not considering index! if current_sum in memo: # Different i values will collide return memo[current_sum] # Include or exclude current number result = dp(i + 1, current_sum + nums[i]) or dp(i + 1, current_sum) memo[current_sum] = result return result return dp(0, 0) # CORRECT: Full state in memoization def can_partition_to_equal_sum_correct(nums): total = sum(nums) if total % 2 != 0: return False target = total // 2 memo = {} def dp(i, current_sum): if current_sum == target: return True if i >= len(nums) or current_sum > target: return False # CORRECT: State is (i, current_sum) if (i, current_sum) in memo: return memo[(i, current_sum)] result = dp(i + 1, current_sum + nums[i]) or dp(i + 1, current_sum) memo[(i, current_sum)] = result return result return dp(0, 0)72:{"json":{"id":"seed_5afe15fdcf4600d57a8a540afc02b4c7","slug":"debugging-algorithmic-code","category":"Data Structures & Algorithms","topic":"Debugging Algorithmic Code","title":"Debugging Algorithmic Code","description":"Master the art of debugging algorithmic code with systematic approaches to identify, diagnose, and fix common bug patterns. Learn to recognize off-by-one errors, integer overflow, incorrect base cases, and develop a methodical debugging mindset that separates expert engineers from novices.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_e0558633b7fa4d79528ae48088333736","title":"Common Bug Patterns in DSA","order":0,"content":[{"id":"opening-hook","title":"The Debugging Imperative","content":[{"data":{"content":"Every programmer, regardless of experience level, knows the frustration of staring at code that *should* work but doesn't. In algorithmic programming, this frustration reaches its apex. You've designed the perfect algorithm, analyzed its complexity, and implemented it with care—yet the tests fail. The output is wrong. Sometimes subtly wrong, sometimes catastrophically wrong.\n\n**Here's the uncomfortable truth:** Debugging algorithmic code is fundamentally different from debugging typical application code. In application development, bugs often manifest as crashes, exceptions, or obviously broken UI. In algorithmic code, bugs are frequently *silent*—the program runs to completion, produces output, and that output is simply... incorrect.\n\nThe difference between junior and senior engineers isn't that seniors write bug-free code. It's that seniors **recognize bug patterns instantly** and debug systematically rather than randomly."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Master","content":"By the end of this page, you will internalize the taxonomy of common algorithmic bugs—the recurring patterns that account for the vast majority of DSA implementation failures. This knowledge transforms debugging from a frustrating hunt into a systematic elimination process. You'll learn to see bugs before you even run the code.","variant":"info"},"type":"callout"}]},{"id":"why-algorithmic-bugs-differ","title":"Why Algorithmic Bugs Are Different","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"items":["**No Stack Trace to Guide You** — The bug isn't in a crashed line; it's in your logic. The program thinks it succeeded, so there's no error to trace back.","**Correctness Is Input-Dependent** — An algorithm might work for 999 test cases and fail on the 1000th because that case triggers a specific boundary condition.","**Small Errors Compound** — A single off-by-one error in an inner loop might produce output that's 'close' to correct, making it hard to pinpoint.","**The Algorithm Might Be Wrong** — Sometimes the bug isn't in implementation but in your understanding of the algorithm itself.","**Performance Bugs Are Logic Bugs** — Exceeding time limits often isn't about 'slow code' but about accidentally hitting O(n²) when you expected O(n log n)."],"title":{"icon":"AlertCircle","text":"Properties That Make Algorithmic Bugs Insidious","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Debugging Trap","content":"Many programmers respond to algorithmic bugs by adding random print statements, tweaking values, or rewriting code without understanding *what* is wrong. This is the debugging equivalent of changing random ingredients when a recipe fails—it occasionally works but teaches nothing and wastes enormous time. Systematic debugging requires recognizing bug *categories*.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"taxonomy-of-bugs","title":"The Taxonomy of Algorithmic Bugs","content":[{"data":{"content":"After analyzing thousands of algorithmic implementations across competitions, interviews, and production systems, distinct patterns emerge. Understanding this taxonomy is the first step toward rapid debugging.\n\n**The Master Categories**\n\nAlgorithmic bugs fall into several overlapping categories. Each category has characteristic symptoms and targeted debugging strategies:"},"type":"text"},{"data":{"rows":[["Boundary Errors","Off-by-one errors, incorrect loop bounds, edge handling","Correct for 'normal' inputs, wrong for boundaries","Medium"],["Overflow/Underflow","Integer limits exceeded, precision loss, sign errors","Works for small inputs, fails for large values","Hard (silent)"],["Initialization Errors","Wrong starting values, uninitialized variables, incorrect defaults","First iteration wrong, cascades through algorithm","Medium"],["Termination Errors","Wrong stopping conditions, infinite loops, premature exits","Hangs, times out, or returns partial results","Easy to Hard"],["State Mutation Errors","Incorrect updates, missing updates, order-of-operation bugs","Cumulative errors across iterations","Hard"],["Recurrence Errors","Wrong recursion formula, missing parameters, incorrect memoization keys","Subtle logical errors in DP/recursion","Very Hard"],["Algorithmic Misunderstanding","Implementing the wrong algorithm for the problem","Systematically wrong output","Very Hard"]],"caption":"Master Taxonomy of Algorithmic Bugs","headers":["Category","Description","Typical Symptom","Difficulty to Find"]},"type":"table"},{"data":{"content":"Notice that **boundary errors** and **overflow errors** are the most common in practice, accounting for perhaps 60-70% of all algorithmic bugs. This is why subsequent pages focus heavily on these categories.\n\n**The Pareto Principle of Bugs**\n\nA small number of bug patterns cause the majority of debugging pain:\n- Off-by-one errors (boundary)\n- Integer overflow (overflow)\n- Incorrect base cases (initialization + termination)\n- Wrong loop bounds (boundary + termination)\n- Uninitialized or incorrectly initialized variables (initialization)\n\nMaster these five patterns, and you eliminate most of your debugging time."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"boundary-error-patterns","title":"Boundary Error Patterns in Detail","content":[{"data":{"content":"Boundary errors are the most common bug category in algorithmic code. They occur when your code doesn't correctly handle the *edges*—the first element, the last element, the empty case, or the single-element case.\n\n**Why Boundaries Are So Error-Prone**\n\nHuman reasoning naturally focuses on the 'happy path'—the typical scenario where everything is in the middle, arrays have many elements, and edge cases don't apply. When designing algorithms, we think about the general case. Boundaries require *exceptional* reasoning:\n\n- \"What if the array is empty?\"\n- \"What if there's only one element?\"\n- \"What if the target is at the very first or very last position?\"\n- \"What happens on the last iteration of the loop?\"\n\nThese questions are easy to forget and their answers are often non-obvious."},"type":"text"},{"data":{"fileName":"boundary_errors_examples.py","languages":[{"code":"$7b","label":"Python","value":"python"},{"code":"$7c","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"items":["**Check your loop bounds:** Is it `< n` or `<= n`? Is it `>= 0` or `> 0`? Verify consistency with your array indexing.","**Verify index arithmetic:** When computing `mid`, `left`, or `right`, trace through what happens at boundaries.","**Test the empty case:** What happens if the input array is empty? Does your code handle it?","**Test the single-element case:** This often reveals off-by-one errors that multi-element tests miss.","**Test the two-element case:** Many algorithms have special behavior when there are exactly two elements.","**Check first/last element handling:** Verify your algorithm finds targets at index 0 and index n-1."],"title":{"icon":"Lightbulb","text":"Boundary Error Detection Checklist","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"initialization-errors","title":"Initialization Error Patterns","content":[{"data":{"content":"Initialization errors occur when variables start with the wrong value. In algorithmic code, incorrect initialization cascades through the entire computation, making the final result wrong even though each step's *logic* might be correct.\n\n**The Initialization-Termination Duality**\n\nInitialization and termination are deeply connected. Your initial values define the *invariant* that your algorithm maintains. If you initialize wrong, either:\n- Your invariant is violated from the start, corrupting all results\n- Your termination condition triggers too early or too late\n- Edge cases (empty input, single element) produce incorrect results\n\n**Common Initialization Mistakes**"},"type":"text"},{"data":{"rows":[["Finding Maximum","max_val = -∞ or first element","max_val = 0","Negative values are ignored"],["Finding Minimum","min_val = +∞ or first element","min_val = 0","Values smaller than 0 are ignored"],["Counting","count = 0","count = 1","Off-by-one in final count"],["Prefix/Cumulative Sum","prefix[0] = 0","Missing or wrong base","All sums offset by a constant"],["Dynamic Programming","dp[0] or dp[base] set explicitly","Only initializing to 0/default","Recurrence breaks on base case"],["Graph traversal","All nodes unvisited initially","Forgetting to mark start visited","Cycles in BFS/DFS"],["Distance array","dist[start] = 0, all others = ∞","All distances = 0","Wrong shortest paths"]],"caption":"Initialization Errors by Algorithm Type","headers":["Algorithm Type","Correct Initialization","Common Mistake","Consequence"]},"type":"table"},{"data":{"fileName":"initialization_errors.py","languages":[{"code":"$7d","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"The 'What's the Base Case?' Test","content":"Before writing any loop or recursion, explicitly ask: 'What's the base case, and what should it return?' Write that initialization first, then verify your loop/recursion correctly builds from there. This one habit prevents the majority of initialization bugs.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"state-mutation-errors","title":"State Mutation and Update Errors","content":[{"data":{"content":"State mutation errors occur when your algorithm incorrectly updates its internal state. These are particularly insidious because the initial values are correct, the loop logic seems correct, but somewhere in the update sequence, something goes wrong.\n\n**Categories of State Mutation Bugs**"},"type":"text"},{"data":{"items":["**Missing Update:** The algorithm forgets to update a variable under certain conditions, leaving it stale.","**Wrong Order of Updates:** Two state variables depend on each other, and updating them in the wrong order uses stale values.","**Premature Update:** Updating state before it's been fully used in the current iteration.","**Overwrite Before Use:** Re-assigning a variable before reading its previous value that was needed.","**In-Place Modification Corruption:** Modifying an array in-place while iterating over it, causing skipped or duplicate processing.","**Reference vs Value Confusion:** In languages with reference semantics, accidentally mutating shared state."],"title":{"icon":"Code2","text":"Types of State Mutation Errors","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"fileName":"state_mutation_errors.py","languages":[{"code":"$7e","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"The 'Trace One Iteration' Test","content":"When suspecting a state mutation bug, manually trace through ONE complete iteration of your loop. Write down the value of every variable at the start of the iteration, after each statement, and at the end. This almost always reveals where the mutation order breaks.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"recurrence-recursion-errors","title":"Recurrence and Recursion Errors","content":[{"data":{"content":"Recurrence errors are bugs in the mathematical relationship your algorithm depends on. These are the hardest bugs to find because the code may perfectly implement a formula—that happens to be the wrong formula.\n\n**Why Recurrence Bugs Are So Difficult**\n\nTypical debugging checks the *implementation*: \"Is the code doing what I think it should?\"\n\nRecurrence bugs require checking the *specification*: \"Is what I think it should do actually correct?\"\n\nThis requires stepping back from the code entirely and re-deriving your algorithm from first principles."},"type":"text"},{"data":{"items":["**Wrong recurrence formula:** The mathematical relationship between subproblems is incorrect.","**Missing subproblem:** You haven't accounted for all cases in your recurrence.","**Wrong parameter space:** The subproblems are parameterized incorrectly, missing important state.","**Incorrect base case handling:** Mismatch between recurrence and base case definitions.","**Memoization key error:** Using incomplete information as the memoization key, causing cache collisions.","**Off-by-one in subproblem indices:** Especially common when translating between 0-indexed and 1-indexed thinking."],"title":{"icon":"AlertCircle","text":"Common Recurrence Errors","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"fileName":"recurrence_errors.py","languages":[{"code":"$7f","label":"Python","value":"python"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Debugging Recurrences: Return to First Principles","content":"When you suspect a recurrence bug, stop looking at code. Take out paper. Re-derive the recurrence from the problem definition. Define: What is dp[i] (or dp[i][j], etc.)? What are ALL the ways the solution can be composed from smaller subproblems? What are ALL the base cases? Compare this to your code line by line.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"bug-recognition-framework","title":"Building Bug Pattern Recognition","content":[{"data":{"content":"Now that we've surveyed the major bug categories, let's synthesize this into a practical framework for rapid bug recognition.\n\n**The Symptom-to-Bug Mapping**\n\nWhen your algorithm produces wrong output, the *nature* of the wrongness often points directly to the bug category:"},"type":"text"},{"data":{"rows":[["Output off by exactly 1","Off-by-one error","Loop bounds, < vs <=, array indexing"],["Correct for small inputs, wrong for large","Integer overflow OR complexity","Data type ranges, check for O(n²) loops"],["Wrong only for edge cases (empty, single)","Boundary/initialization error","Base cases, empty checks, first/last element"],["Correct for first few iterations, then wrong","State mutation order","Trace update order, check temp variables"],["Totally wrong output (not just off by a bit)","Recurrence/algorithm error","Re-derive the algorithm on paper"],["Timeout (too slow)","Complexity bug","Look for hidden O(n²) or missing memoization"],["Random/inconsistent failures","Uninitialized variable","Check all variables have explicit initial values"],["Works in test, fails in submission","Integer overflow (often)","Check for intermediate calculations exceeding limits"]],"caption":"Symptom-Based Bug Identification","headers":["Symptom","Likely Bug Category","First Things to Check"]},"type":"table"},{"data":{"content":"**The Systematic Debugging Mindset**\n\nWhen facing a bug, resist the urge to randomly modify code. Instead:\n\n1. **Classify the symptom:** What type of wrongness am I seeing?\n2. **Hypothesize the bug category:** Based on the symptom, which bug type is most likely?\n3. **Check targeted locations:** Look at the specific code patterns associated with that bug type.\n4. **Verify with minimal input:** Construct the smallest possible input that triggers the bug.\n5. **Trace manually:** Walk through the algorithm step-by-step with that input.\n\nThis process is faster than random debugging because you're not searching the entire codebase—you're searching a narrow set of likely locations."},"type":"text"},{"data":{"icon":"CheckCircle","title":"The Expert's Advantage","content":"Expert debuggers don't have superhuman concentration or patience. They simply recognize patterns faster. When they see 'off by 1' output, their brain immediately narrows to loop bounds and indexing. When they see timeout, they immediately look for hidden quadratic behavior. This pattern library is what you're building by studying bug categories.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: Mastering Bug Patterns","content":[{"data":{"content":"We've surveyed the landscape of algorithmic bugs. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Algorithmic bugs are different** — They're silent, often producing plausible-looking wrong output with no error messages.","**A small set of patterns causes most bugs** — Off-by-one, overflow, initialization, and termination errors account for the majority of failures.","**Symptom points to diagnosis** — The *type* of wrong output guides you to the *type* of bug, dramatically narrowing your search.","**Systematic beats random** — Classifying bugs and checking targeted locations vastly outperforms random code modification.","**Manual tracing is underrated** — Walking through code by hand with a minimal failing input almost always reveals the bug.","**Recurrence bugs require re-derivation** — Sometimes the implementation is correct but the algorithm is wrong; this requires returning to first principles."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next**\n\nThe following pages dive deep into specific bug categories:\n- **Page 2:** Off-by-one errors in exhaustive detail\n- **Page 3:** Integer overflow and how to prevent it\n- **Page 4:** Incorrect base cases in recursion and DP\n- **Page 5:** Systematic debugging approaches and methodologies\n\nEach page provides targeted practice and a mental model for that specific bug pattern. By the end of this module, debugging will transform from an art to a science."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive taxonomy of algorithmic bug patterns. This mental map transforms debugging from a frustrating hunt into systematic elimination. In the next pages, we'll dive deep into the most common and dangerous bug types.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_ab7adc3f24c8d9e4bbb6fe542dc505fb","title":"Off-by-One Errors","order":1,"content":null,"isLocked":true},{"id":"seed_2800adc37dc680b44d856c09c7389d7e","title":"Integer Overflow","order":2,"content":null,"isLocked":true},{"id":"seed_fe26f0d0c4cc4404d87c5f57e4cd3eed","title":"Incorrect Base Cases","order":3,"content":null,"isLocked":true},{"id":"seed_963326e19521e0b5fa77a51b668f3348","title":"Systematic Debugging Approach","order":4,"content":null,"isLocked":true}]}}