Activity Selection Problem in DSA Rust - Time & Space Complexity

Time Complexity: Activity Selection Problem

O(n)

Understanding Time Complexity

We want to understand how the time needed to select activities grows as the number of activities increases.

How does the program's work change when we have more activities to choose from?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

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

This code picks the maximum number of activities that don't overlap, assuming activities are sorted by finish time.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: A single loop that checks each activity once.
• How many times: The loop runs once for each activity after the first, so n-1 times.

How Execution Grows With Input

As the number of activities grows, the program checks each one once to decide if it fits.

Input Size (n)	Approx. Operations
10	About 9 checks
100	About 99 checks
1000	About 999 checks

Pattern observation: The number of checks grows directly with the number of activities.

Final Time Complexity

Time Complexity: O(n)

This means the time needed grows in a straight line with the number of activities.

Common Mistake

[X] Wrong: "The loop runs inside another loop, so it must be O(n²)."

[OK] Correct: There is only one loop that goes through the activities once, so the work is linear, not squared.

Interview Connect

Understanding this helps you explain how to efficiently pick tasks without overlap, a common real-world problem.

Self-Check

"What if the activities were not sorted by finish time? How would the time complexity change?"

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