Greedy vs DP How to Know Which to Apply in DSA Rust - Compare & Choose

Challenge - 5 Problems

🧠 Conceptual

intermediate

When to use Greedy vs Dynamic Programming?

Which statement best describes when to use a greedy algorithm instead of dynamic programming?

A Use greedy when overlapping subproblems require storing intermediate results.

B Use greedy when local choices lead to a global optimum without revisiting decisions.

C Use greedy when the problem requires exploring all possible combinations.

D Use greedy when the problem has no optimal substructure property.

💡 Hint

Think about whether making the best immediate choice guarantees the best overall solution.

Greedy algorithms work when choosing the best option at each step leads to the best overall solution. Dynamic programming is needed when decisions depend on previous choices and subproblems overlap.

❓ Predict Output

intermediate

Output of Greedy Coin Change Algorithm

What is the output of this Rust code that uses a greedy approach to make change?

DSA Rust

fn greedy_coin_change(mut amount: i32, coins: &[i32]) -> Vec<i32> {
    let mut result = Vec::new();
    for &coin in coins {
        let count = amount / coin;
        amount %= coin;
        result.push(count);
    }
    result
}

fn main() {
    let coins = [25, 10, 5, 1];
    let amount = 63;
    let counts = greedy_coin_change(amount, &coins);
    println!("{:?}", counts);
}

A [2, 1, 0, 3]

B [2, 1, 0, 4]

C [2, 0, 2, 3]

D [1, 3, 0, 3]

💡 Hint

Divide amount by each coin value starting from largest coin.

The code divides 63 by 25 to get 2 coins, remainder 13. Then 13 by 10 is 1 coin, remainder 3. Then 3 by 5 is 0 coins, remainder 3. Finally 3 by 1 is 3 coins.

❓ Predict Output

advanced

Dynamic Programming Fibonacci Output

What is the output of this Rust code that uses dynamic programming to compute Fibonacci numbers?

DSA Rust

fn fib_dp(n: usize) -> usize {
    let mut dp = vec![0; n + 1];
    dp[0] = 0;
    if n > 0 {
        dp[1] = 1;
    }
    for i in 2..=n {
        dp[i] = dp[i - 1] + dp[i - 2];
    }
    dp[n]
}

fn main() {
    println!("{}", fib_dp(7));
}

A 34

B 21

C 8

D 13

💡 Hint

Recall Fibonacci sequence: 0,1,1,2,3,5,8,13,...

fib_dp(7) returns the 7th Fibonacci number (0-based index), which is 13.

🔧 Debug

advanced

Why does this greedy algorithm fail for coin change?

Consider this Rust code for coin change using a greedy approach. Why does it fail for amount = 30 with coins [25, 10, 6, 1]?

fn greedy_coin_change(mut amount: i32, coins: &[i32]) -> Vec {
    let mut result = Vec::new();
    for &coin in coins {
        let count = amount / coin;
        amount %= coin;
        result.push(count);
    }
    result
}

fn main() {
    let coins = [25, 10, 6, 1];
    let amount = 30;
    let counts = greedy_coin_change(amount, &coins);
    println!("{:?}", counts);
}

A Greedy picks 6 coins first, which is incorrect order.

B Greedy algorithm always works for coin change, so no failure.

C Greedy picks 25 once and then 5 ones, missing the better solution with 3 tens.

D Greedy picks 10 coins first, which is not optimal.

💡 Hint

Try to find the minimum coins needed for 30 with given coins.

The greedy approach picks 25 once, then 5 coins of 1, totaling 6 coins. But the optimal solution is 3 coins of 10, totaling 3 coins. Greedy fails because local best choice (25) is not part of global best solution.

🚀 Application

expert

Choosing Algorithm for Weighted Interval Scheduling

You have a list of jobs with start time, end time, and profit. You want to select jobs that don't overlap and maximize total profit. Which approach is best?

A Use dynamic programming to consider previous compatible jobs and maximize profit.

B Use a greedy algorithm by always picking the job with the highest profit first.

C Use a simple loop to pick jobs in order of start time without checking overlaps.

D Use a brute force approach to try all combinations without optimization.

💡 Hint

Think about overlapping intervals and how to combine solutions.

Weighted interval scheduling requires checking previous compatible jobs to maximize profit, which dynamic programming handles efficiently. Greedy by profit alone can fail due to overlaps.

Practice

1. Which of the following best describes when to use a greedy algorithm instead of dynamic programming?

easy

A. When the problem has overlapping subproblems and no optimal substructure

B. When the problem has an optimal substructure and no overlapping subproblems

C. When the problem requires checking all possible solutions

D. When the problem is unsolvable

Solution

1. Step 1: Understand greedy algorithm conditions

   Greedy algorithms work when choosing the best option at each step leads to a global optimum, which means the problem has an optimal substructure and no overlapping subproblems.

2. Step 2: Compare with dynamic programming conditions

   Dynamic programming is used when the problem has overlapping subproblems and optimal substructure, requiring storing intermediate results.

3. Final Answer:

   When the problem has an optimal substructure and no overlapping subproblems -> Option B

4. Quick Check:

   Greedy = optimal substructure + no overlap [OK]

Hint: Use greedy if no overlapping subproblems exist [OK]

Common Mistakes:

• Confusing overlapping subproblems as a greedy condition
• Using DP when greedy suffices
• Assuming greedy always finds optimal solution
• Ignoring problem structure before choosing approach

2. Which Rust code snippet correctly declares a vector and uses it to implement a greedy approach for selecting intervals sorted by end time?

easy

A. let intervals = vec![(1,3), (2,5), (4,7)]; intervals.reverse();

B. let intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort();

C. let mut intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort_by(|a,b| a.0.cmp(&b.0));

D. let mut intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort_by_key(|k| k.1);

Solution

1. Step 1: Identify correct vector declaration and sorting

   let mut intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort_by_key(|k| k.1); declares a mutable vector and sorts it by the second element (end time), which is needed for greedy interval scheduling.

2. Step 2: Check other options for correctness

   let intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort(); tries to sort an immutable vector and uses default sort (by first element), let mut intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort_by(|a,b| a.0.cmp(&b.0)); sorts by start time, not end time, and let intervals = vec![(1,3), (2,5), (4,7)]; intervals.reverse(); reverses without sorting.

3. Final Answer:

   let mut intervals = vec![(1,3), (2,5), (4,7)]; intervals.sort_by_key(|k| k.1); -> Option D

4. Quick Check:

   Sort intervals by end time with mutable vector [OK]

Hint: Sort intervals by end time for greedy scheduling [OK]

Common Mistakes:

• Sorting by start time instead of end time
• Using immutable vector when sorting is needed
• Not sorting intervals before greedy selection
• Using reverse instead of sort

3. What is the output of the following Rust code implementing a greedy approach to select maximum intervals?

let mut intervals = vec![(1,3), (2,5), (4,7)];
intervals.sort_by_key(|k| k.1);
let mut count = 0;
let mut end = 0;
for &(start, finish) in &intervals {
    if start >= end {
        count += 1;
        end = finish;
    }
}
println!("{}", count);

medium

A. 2

B. 3

C. 1

D. 0

Solution

1. Step 1: Sort intervals by end time

   Sorted intervals: (1,3), (2,5), (4,7)

2. Step 2: Iterate and count non-overlapping intervals

   First interval (1,3): start=1 >= end=0, count=1, end=3 Second interval (2,5): start=2 < end=3, skip Third interval (4,7): start=4 >= end=3, count=2, end=7

3. Final Answer:

   2 -> Option A

4. Quick Check:

   Greedy interval count = 2 [OK]

Hint: Count intervals where start >= last end [OK]

Common Mistakes:

• Counting overlapping intervals
• Not updating end after selection
• Sorting incorrectly
• Confusing start and end values

4. The following Rust code attempts to solve the coin change problem using a greedy approach. What is the bug?

let coins = vec![1, 3, 4];
let mut amount = 6;
let mut count = 0;
for &coin in coins.iter().rev() {
    while amount >= coin {
        amount -= coin;
        count += 1;
    }
}
println!("{}", count);

medium

A. The amount variable is not mutable

B. The coins vector is not sorted ascending

C. Greedy fails because coin denominations do not guarantee optimal solution

D. The loop should not reverse the coins vector

Solution

1. Step 1: Understand greedy coin change limitation

   Greedy works only if coin denominations are canonical (like 1,5,10). Here, 1,3,4 can cause greedy to fail.

2. Step 2: Check code behavior

   Greedy picks 4 once (amount=2), then picks 1 twice (total 3 coins). But optimal is 2 coins (3+3).

3. Final Answer:

   Greedy fails because coin denominations do not guarantee optimal solution -> Option C

4. Quick Check:

   Greedy fails on non-canonical coins [OK]

Hint: Greedy fails if coin set is not canonical [OK]

Common Mistakes:

• Assuming greedy always works for coin change
• Ignoring coin order importance
• Not checking for optimal substructure
• Confusing mutability of variables

5. You want to find the minimum number of coins to make amount 6 using coins [1, 3, 4]. Which approach is best and why? A) Greedy picking largest coin first B) Brute force checking all combinations C) Dynamic programming storing minimum coins for each amount D) Sorting coins ascending and picking smallest first

hard

A. Dynamic programming storing minimum coins for each amount

B. Brute force checking all combinations

C. Greedy picking largest coin first

D. Sorting coins ascending and picking smallest first

Solution

1. Step 1: Analyze greedy approach limitations

   Greedy may pick 4 then 1s, resulting in 3 coins, but optimal is 2 coins (3+3).

2. Step 2: Understand dynamic programming advantage

   DP stores minimum coins needed for each amount, ensuring optimal solution even with tricky coin sets.

3. Step 3: Compare other options

   Brute force is slow; sorting ascending and picking smallest first is not optimal strategy.

4. Final Answer:

   Dynamic programming storing minimum coins for each amount -> Option A

5. Quick Check:

   DP handles overlapping subproblems for optimal coin count [OK]

Hint: Use DP for minimum coins with tricky denominations [OK]

Common Mistakes:

• Using greedy for non-canonical coin sets
• Ignoring performance of brute force
• Assuming sorting smallest first helps
• Not recognizing overlapping subproblems