Memoization Top Down DP in DSA Rust

Mental Model

Remember answers to smaller problems so you don't solve them again.

Analogy: Like writing down answers to tricky homework questions so you can check them later instead of redoing the whole problem.

Problem -> Break into smaller problems -> Solve smaller problems -> Store answers in a table (memo) -> Use stored answers to build bigger answers

Dry Run Walkthrough

Input: Calculate Fibonacci number for n=5 using memoization

Goal: Find fib(5) efficiently by storing results of fib(0) to fib(5) to avoid repeated work

Step 1: Call fib(5), memo empty

memo: []

Why: Start solving the big problem fib(5)

Step 2: fib(5) calls fib(4) and fib(3)

memo: []

Why: Break fib(5) into smaller fib(4) and fib(3)

Step 3: fib(4) calls fib(3) and fib(2)

memo: []

Why: Break fib(4) further

Step 4: fib(3) calls fib(2) and fib(1)

memo: []

Why: Keep breaking down until base cases

Step 5: fib(2) calls fib(1) and fib(0), both base cases return 1 and 0

memo: []

Why: Base cases return known values

Step 6: fib(2) = 1 + 0 = 1, store memo[2] = 1

memo: [_, _, 1, _, _, _]

Why: Store result to avoid recomputation

Step 7: fib(3) = fib(2) + fib(1) = 1 + 1 = 2, store memo[3] = 2

memo: [_, _, 1, 2, _, _]

Why: Use stored fib(2) and base fib(1)

Step 8: fib(4) = fib(3) + fib(2) = 2 + 1 = 3, store memo[4] = 3

memo: [_, _, 1, 2, 3, _]

Why: Use stored fib(3) and fib(2)

Step 9: fib(3) called again from fib(5), found in memo as 2, no recomputation

memo: [_, _, 1, 2, 3, _]

Why: Memoization avoids repeated work

Step 10: fib(5) = fib(4) + fib(3) = 3 + 2 = 5, store memo[5] = 5

memo: [_, _, 1, 2, 3, 5]

Why: Final answer stored

Result:

memo: [_, _, 1, 2, 3, 5]
fib(5) = 5

Annotated Code

DSA Rust

use std::collections::HashMap;

fn fib(n: usize, memo: &mut HashMap<usize, usize>) -> usize {
    if n == 0 {
        return 0; // base case
    }
    if n == 1 {
        return 1; // base case
    }
    if let Some(&val) = memo.get(&n) {
        return val; // return stored result
    }
    let result = fib(n - 1, memo) + fib(n - 2, memo); // recursive calls
    memo.insert(n, result); // store result
    result
}

fn main() {
    let n = 5;
    let mut memo = HashMap::new();
    let result = fib(n, &mut memo);
    println!("fib({}) = {}", n, result);
}

if n == 0 { return 0; }

return base case fib(0) = 0

if n == 1 { return 1; }

return base case fib(1) = 1

if let Some(&val) = memo.get(&n) { return val; }

return memoized result if available

let result = fib(n - 1, memo) + fib(n - 2, memo);

compute fib(n) recursively

memo.insert(n, result);

store computed result in memo

Output

fib(5) = 5

Complexity Analysis

Time: O(n) because each fib number from 0 to n is computed once and stored

Space: O(n) for the memo table storing results for each subproblem

vs Alternative: Compared to naive recursion with O(2^n) time, memoization reduces repeated work drastically

Edge Cases

n = 0 (smallest input)

Returns 0 immediately from base case

DSA Rust

if n == 0 { return 0; }

n = 1 (smallest non-zero input)

Returns 1 immediately from base case

DSA Rust

if n == 1 { return 1; }

Repeated calls for same n

Returns stored result from memo without recomputation

DSA Rust

if let Some(&val) = memo.get(&n) { return val; }

When to Use This Pattern

When a problem asks for a value defined by overlapping subproblems and recursion, use memoization top-down DP to store and reuse results to avoid repeated work.

Common Mistakes

Mistake: Not checking memo before recursive calls, causing repeated work
Fix: Always check if result is in memo before computing recursively

Mistake: Not storing computed results in memo after recursion
Fix: Insert the computed result into memo before returning

Summary

Stores answers to smaller problems to avoid repeated calculations in recursion.

Use when a problem has overlapping subproblems and can be broken down recursively.

The key is to remember and reuse results instead of recomputing them.

Practice

1. What is the main purpose of memoization in top-down dynamic programming?

easy

A. To store results of subproblems to avoid repeated calculations

B. To sort the input data before processing

C. To convert recursive code into iterative code

D. To reduce memory usage by deleting variables

Solution

1. Step 1: Understand memoization role

   Memoization saves results of subproblems so they are not recalculated multiple times.

2. Step 2: Compare options

   Only To store results of subproblems to avoid repeated calculations describes this purpose correctly. Sorting, converting recursion, or deleting variables are unrelated.

3. Final Answer:

   To store results of subproblems to avoid repeated calculations -> Option A

4. Quick Check:

   Memoization = store subproblem results [OK]

Hint: Memoization means saving answers to reuse later [OK]

Common Mistakes:

• Confusing memoization with sorting
• Thinking memoization reduces memory by deleting data
• Believing memoization changes recursion to iteration

2. Which of the following Rust code snippets correctly declares a memoization cache for a function with input type usize and output type usize?

easy

A. let memo: Vec<usize> = Vec::new();

B. let memo = HashMap::new();

C. let mut memo: Vec = vec![None; n + 1];

D. let mut memo: Vec<usize> = vec![0; n];

Solution

1. Step 1: Identify correct memo type

   Memoization cache should store Option<usize> to mark computed or not, initialized with None.

2. Step 2: Check each option

   let mut memo: Vec = vec![None; n + 1]; uses Vec with None values, correct for memoization. let memo = HashMap::new(); is a HashMap but missing mut and initialization syntax. let memo: Vec<usize> = Vec::new(); lacks Option type. let mut memo: Vec<usize> = vec![0; n]; uses usize with zeros, which can't distinguish computed or not.

3. Final Answer:

   let mut memo: Vec = vec![None; n + 1]; -> Option C

4. Quick Check:

   Memo cache = Vec with None [OK]

Hint: Use Option type to mark uncomputed states [OK]

Common Mistakes:

• Using Vec<usize> without Option to track computed
• Not making memo mutable
• Incorrect initialization of HashMap

3. Consider this Rust function using memoization to compute Fibonacci numbers:

fn fib(n: usize, memo: &mut Vec) -> usize {
    if n <= 1 {
        return n;
    }
    if let Some(val) = memo[n] {
        return val;
    }
    let result = fib(n - 1, memo) + fib(n - 2, memo);
    memo[n] = Some(result);
    result
}

fn main() {
    let n = 5;
    let mut memo = vec![None; n + 1];
    println!("{}", fib(n, &mut memo));
}

What is the output when this code runs?

medium

A. 8

B. 5

C. 3

D. 13

Solution

1. Step 1: Understand Fibonacci calculation

   fib(5) = fib(4) + fib(3). Calculating recursively with memoization avoids repeated work.

2. Step 2: Calculate fib(5)

   fib(0)=0, fib(1)=1, fib(2)=1, fib(3)=2, fib(4)=3, fib(5)=5.

3. Final Answer:

   5 -> Option B

4. Quick Check:

   fib(5) = 5 [OK]

Hint: Recall Fibonacci sequence: 0,1,1,2,3,5... [OK]

Common Mistakes:

• Confusing fib(5) with fib(6)
• Forgetting zero-based indexing
• Ignoring memoization effect

4. This Rust code tries to memoize the factorial function but has a bug:

fn fact(n: usize, memo: &mut Vec) -> usize {
    if n == 0 {
        return 1;
    }
    if memo[n].is_some() {
        return memo[n].unwrap();
    }
    let result = n * fact(n - 1, memo);
    memo[n] = Some(result);
    result
}

fn main() {
    let n = 5;
    let mut memo = vec![None; n];
    println!("{}", fact(n, &mut memo));
}

What is the bug causing a runtime error?

medium

A. The memo vector size is too small causing index out of bounds

B. The base case should return 0 instead of 1

C. The function does not update memo correctly

D. The function should not use recursion

Solution

1. Step 1: Check memo vector size

   Memo is created with size n (5), but fact accesses memo[n], which is memo[5], out of bounds since indices go 0 to 4.

2. Step 2: Identify cause of runtime error

   Accessing memo[5] causes panic due to index out of bounds. The vector should be size n+1 to include index 5.

3. Final Answer:

   The memo vector size is too small causing index out of bounds -> Option A

4. Quick Check:

   Vector size < needed index = runtime error [OK]

Hint: Memo size must cover all indices used [OK]

Common Mistakes:

• Ignoring vector size when indexing
• Changing base case incorrectly
• Thinking recursion is the problem

5. You want to use top-down memoization in Rust to count the number of ways to climb a staircase of n steps, taking 1 or 2 steps at a time. Which of these implementations correctly applies memoization to avoid repeated calculations?

fn climb(n: usize, memo: &mut Vec) -> usize {
    if n == 0 {
        return 1;
    }
    if n < 0 {
        return 0;
    }
    if let Some(val) = memo[n] {
        return val;
    }
    let ways = climb(n - 1, memo) + climb(n - 2, memo);
    memo[n] = Some(ways);
    ways
}

fn main() {
    let n = 4;
    let mut memo = vec![None; n + 1];
    println!("{}", climb(n, &mut memo));
}

hard

A. Incorrect because it does not handle negative indices safely

B. Incorrect because it uses iteration instead of recursion

C. Incorrect because memo vector is not mutable

D. Correct implementation with proper base cases and memo usage

Solution

1. Step 1: Check base cases and recursion

   Base cases handle n == 0 (1 way) and n < 0 (0 ways), which is correct for counting ways.

2. Step 2: Verify memoization usage

   Memo vector is mutable and stores Option<usize>. It checks memo[n] before recursion and stores result after calculation.

3. Step 3: Confirm no unsafe indexing

   Negative n returns 0 before indexing memo, so no out-of-bounds access.

4. Final Answer:

   Correct implementation with proper base cases and memo usage -> Option D

5. Quick Check:

   Base cases + memo check = correct memoization [OK]

Hint: Check base cases and memo before recursion [OK]

Common Mistakes:

• Not handling negative n before memo access
• Forgetting to make memo mutable
• Using iteration instead of recursion in top-down DP