Activity Selection Problem in DSA Rust - Practice Problems & Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of Greedy Activity Selection

What is the output of the following Rust code that selects the maximum number of non-overlapping activities?

DSA Rust

fn activity_selection(start: &[i32], finish: &[i32]) -> Vec<usize> {
    let n = start.len();
    let mut selected = vec![0];
    let mut last_finish = finish[0];
    for i in 1..n {
        if start[i] >= last_finish {
            selected.push(i);
            last_finish = finish[i];
        }
    }
    selected
}

fn main() {
    let start = [1, 3, 0, 5, 8, 5];
    let finish = [2, 4, 6, 7, 9, 9];
    let result = activity_selection(&start, &finish);
    println!("{:?}", result);
}

A [0, 1, 4]

B [0, 2, 3, 5]

C [1, 3, 4]

D [0, 1, 3, 4]

💡 Hint

Remember the activities are selected based on earliest finish time and non-overlapping start times.

The code selects activities starting with the first one (index 0). It then picks the next activity whose start time is at least the finish time of the last selected activity. The selected indices are [0, 1, 3, 4].

🧠 Conceptual

intermediate

Key Idea Behind Activity Selection Problem

Which of the following best describes the main idea behind the greedy solution to the Activity Selection Problem?

A Always pick the activity with the earliest start time.

B Always pick the activity with the shortest duration.

C Always pick the activity that finishes earliest and is compatible with previously selected activities.

D Always pick the activity that starts latest.

💡 Hint

Think about how to leave room for as many activities as possible.

The greedy approach picks the activity that finishes earliest to maximize the remaining time for other activities.

🔧 Debug

advanced

Identify the Bug in Activity Selection Code

What error will the following Rust code produce when run?

DSA Rust

fn activity_selection(start: &[i32], finish: &[i32]) -> Vec<usize> {
    let n = start.len();
    let mut selected = Vec::new();
    let mut last_finish = finish[0];
    for i in 1..n {
        if start[i] > last_finish {
            selected.push(i);
            last_finish = finish[i];
        }
    }
    selected
}

fn main() {
    let start = [1, 3, 0, 5, 8, 5];
    let finish = [2, 4, 6, 7, 9, 9];
    let result = activity_selection(&start, &finish);
    println!("{:?}", result);
}

A Output is missing the first activity index

B Panic due to accessing finish[0] when vector is empty

C Compilation error due to missing semicolon

D Output includes overlapping activities

💡 Hint

Check if the first activity is added to the selected list.

The code never adds the first activity (index 0) to the selected list, so the output misses it.

❓ Predict Output

advanced

Output of Activity Selection with Unsorted Input

What is the output of this Rust code that attempts activity selection without sorting activities by finish time?

DSA Rust

fn activity_selection_unsorted(start: &mut [i32], finish: &mut [i32]) -> Vec<usize> {
    let n = start.len();
    let mut selected = vec![0];
    let mut last_finish = finish[0];
    for i in 1..n {
        if start[i] >= last_finish {
            selected.push(i);
            last_finish = finish[i];
        }
    }
    selected
}

fn main() {
    let mut start = [5, 1, 3, 0, 8, 5];
    let mut finish = [7, 2, 4, 6, 9, 9];
    let result = activity_selection_unsorted(&mut start, &mut finish);
    println!("{:?}", result);
}

A [0, 4]

B [0, 2, 4]

C [1, 2, 4]

D [0, 1, 3, 4]

💡 Hint

The input is not sorted by finish time, so the greedy approach may fail.

Without sorting by finish time, the code selects activities 0 and 4 only, missing others that could fit.

🧠 Conceptual

expert

Why Sorting by Finish Time is Crucial in Activity Selection

Why must activities be sorted by their finish times before applying the greedy activity selection algorithm?

A To minimize the total duration of selected activities.

B To guarantee the selection of the maximum number of compatible activities.

C To ensure the activities are processed in the order they start.

D To avoid runtime errors during selection.

💡 Hint

Think about how the earliest finishing activity affects the remaining time.

Sorting by finish time ensures the greedy choice picks the earliest finishing activity, maximizing room for others.

Practice

1. What is the main goal of the Activity Selection Problem?

easy

A. Calculate the total duration of all activities

B. Select the maximum number of activities that don't overlap in time

C. Sort activities by their start time

D. Find the activity with the longest duration

Solution

1. Step 1: Understand the problem objective

   The Activity Selection Problem aims to choose the largest set of activities that do not overlap in their time intervals.

2. Step 2: Identify the correct goal

   Among the options, only selecting the maximum number of non-overlapping activities matches the problem's goal.

3. Final Answer:

   Select the maximum number of activities that don't overlap in time -> Option B

4. Quick Check:

   Goal = Max non-overlapping activities [OK]

Hint: Focus on maximizing non-overlapping activities [OK]

Common Mistakes:

• Confusing longest duration with maximum count
• Sorting by start time only
• Summing durations instead of counting activities

2. Which Rust code snippet correctly sorts a vector of activities by their finish time? Assume each activity is a tuple (start: i32, finish: i32).

easy

A. activities.sort_by_key(|a| a.1);

B. activities.sort_by_key(|a| a.0);

C. activities.sort_unstable_by(|a, b| b.1.cmp(&a.1));

D. activities.sort_by(|a, b| a.0.cmp(&b.0));

Solution

1. Step 1: Identify sorting key for finish time

   Each activity is a tuple (start, finish). The finish time is at index 1.

2. Step 2: Choose correct sorting method

   Sorting by finish time ascending uses sort_by_key(|a| a.1). activities.sort_by_key(|a| a.1); matches this.

3. Final Answer:

   activities.sort_by_key(|a| a.1); -> Option A

4. Quick Check:

   Sort by finish time = a.1 [OK]

Hint: Sort activities by finish time using .sort_by_key(|a| a.1) [OK]

Common Mistakes:

• Sorting by start time instead of finish time
• Sorting in descending order incorrectly
• Using unstable sort unnecessarily

3. What is the output of the following Rust code that implements the activity selection logic?

let mut activities = vec![(1, 4), (3, 5), (0, 6), (5, 7), (8, 9), (5, 9)];
activities.sort_by_key(|a| a.1);
let mut selected = vec![activities[0]];
let mut last_finish = activities[0].1;
for &activity in &activities[1..] {
    if activity.0 >= last_finish {
        selected.push(activity);
        last_finish = activity.1;
    }
}
println!("{:?}", selected);

medium

A. [(1, 4), (3, 5), (5, 7), (8, 9)]

B. [(0, 6), (5, 7), (8, 9)]

C. [(1, 4), (5, 7), (8, 9)]

D. [(1, 4), (5, 9)]

Solution

1. Step 1: Sort activities by finish time

   Sorted activities: [(1,4), (3,5), (0,6), (5,7), (8,9), (5,9)]

2. Step 2: Select activities greedily

   Start with (1,4). Next, (3,5) starts before 4, skip. (0,6) starts before 4, skip. (5,7) starts at 5 ≥ 4, select. (8,9) starts at 8 ≥ 7, select. (5,9) starts at 5 < 7, skip.

3. Final Answer:

   [(1, 4), (5, 7), (8, 9)] -> Option C

4. Quick Check:

   Greedy selection = [(1,4),(5,7),(8,9)] [OK]

Hint: Pick earliest finishing activities that start after last finish [OK]

Common Mistakes:

• Selecting overlapping activities
• Not sorting by finish time first
• Including activities starting before last finish

4. Identify the bug in this Rust code snippet for the Activity Selection Problem:

let mut activities = vec![(1, 3), (2, 5), (4, 7)];
activities.sort_by_key(|a| a.0);
let mut selected = vec![activities[0]];
let mut last_finish = activities[0].1;
for &activity in &activities[1..] {
    if activity.0 > last_finish {
        selected.push(activity);
        last_finish = activity.1;
    }
}
println!("{:?}", selected);

medium

A. Using > instead of >= in the if condition

B. Not pushing the first activity into selected

C. Not initializing last_finish correctly

D. Sorting by start time instead of finish time

Solution

1. Step 1: Check sorting criteria

   The code sorts activities by start time (a.0), but the greedy approach requires sorting by finish time.

2. Step 2: Understand impact of sorting

   Sorting by start time breaks the greedy logic, causing incorrect selection of activities.

3. Final Answer:

   Sorting by start time instead of finish time -> Option D

4. Quick Check:

   Sort by finish time needed, not start time [OK]

Hint: Always sort activities by finish time, not start time [OK]

Common Mistakes:

• Sorting by start time
• Using strict > instead of >= (less critical)
• Incorrect initialization of last_finish

5. Given a list of activities with start and finish times, how would you modify the standard Activity Selection Problem to select activities that maximize total duration instead of count? Which approach is correct?

hard

A. Use dynamic programming to consider all subsets and maximize total duration

B. Sort activities by start time and greedily pick those with longest duration

C. Sort by finish time and pick activities with shortest duration first

D. Select activities randomly and check total duration

Solution

1. Step 1: Understand difference in optimization goal

   Maximizing total duration is different from maximizing count; greedy approach fails here.

2. Step 2: Choose correct algorithmic approach

   Dynamic programming can consider all subsets to find the maximum total duration without overlaps.

3. Final Answer:

   Use dynamic programming to consider all subsets and maximize total duration -> Option A

4. Quick Check:

   Max total duration needs DP, not greedy [OK]

Hint: Max duration needs DP, not greedy selection [OK]

Common Mistakes:

• Trying greedy for max duration
• Sorting by start time only
• Random selection without logic