Sorting Stability and When to Use Which Sort in DSA Rust - Practice Problems & Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this stable sort on a list of tuples?

Given a list of tuples representing (name, score), what is the output after applying a stable sort by score?

DSA Rust

let mut data = vec![
    ("Alice", 90),
    ("Bob", 85),
    ("Charlie", 90),
    ("Dave", 85),
];
data.sort_by_key(|k| k.1);
println!("{:?}", data);

A [("Alice", 90), ("Charlie", 90), ("Bob", 85), ("Dave", 85)]

B [("Bob", 85), ("Dave", 85), ("Alice", 90), ("Charlie", 90)]

C [("Dave", 85), ("Bob", 85), ("Charlie", 90), ("Alice", 90)]

D [("Charlie", 90), ("Alice", 90), ("Dave", 85), ("Bob", 85)]

💡 Hint

Stable sort keeps the original order of equal elements.

Rust's sort_by_key is stable, so elements with the same score keep their original order.

🧠 Conceptual

intermediate

When should you prefer a stable sort over an unstable sort?

Choose the best reason to use a stable sort instead of an unstable sort.

A When the data is already sorted and you want to skip sorting.

B When you want the fastest possible sorting regardless of order.

C When you want to preserve the relative order of equal elements after sorting.

D When you want to sort elements in descending order only.

💡 Hint

Think about what 'stable' means in sorting.

Stable sorting keeps equal elements in their original order, which is important when that order carries meaning.

❓ Predict Output

advanced

What error occurs when using an unstable sort with a custom comparator that is not consistent?

Consider this Rust code using sort_unstable_by with a comparator that violates strict ordering rules. What happens?

DSA Rust

let mut nums = vec![3, 1, 2];
nums.sort_unstable_by(|a, b| {
    if *a == 2 && *b == 3 {
        std::cmp::Ordering::Less
    } else if *a == 3 && *b == 2 {
        std::cmp::Ordering::Greater
    } else {
        a.cmp(b)
    }
});
println!("{:?}", nums);

A The code compiles but causes a panic at runtime due to inconsistent comparator.

B The code compiles and prints a sorted vector without errors.

C The code fails to compile due to type mismatch.

D The code runs but prints the original unsorted vector.

💡 Hint

Think about what happens if the comparator is not consistent.

An inconsistent comparator breaks sorting assumptions, causing sort_unstable_by to panic at runtime.

🚀 Application

advanced

Which sorting algorithm is best for sorting a nearly sorted large dataset?

You have a large list that is almost sorted except for a few elements. Which sorting algorithm is most efficient to use?

A Insertion sort, because it performs well on nearly sorted data.

B Selection sort, because it always scans the entire list.

C Bubble sort, because it swaps adjacent elements repeatedly.

D Heap sort, because it builds a heap structure.

💡 Hint

Consider which algorithm benefits from partial order.

Insertion sort is efficient for nearly sorted data as it only moves misplaced elements.

🧠 Conceptual

expert

Why might an unstable sort be preferred over a stable sort in some cases?

Choose the best explanation for preferring an unstable sort over a stable sort.

A Unstable sorts are easier to implement correctly.

B Unstable sorts always produce the same output as stable sorts.

C Unstable sorts guarantee the original order of equal elements.

D Unstable sorts are often faster and use less memory when stability is not required.

💡 Hint

Think about trade-offs between speed and stability.

Unstable sorts can be faster and use less memory but do not preserve order of equal elements.

Practice

1. What does it mean when a sorting algorithm is stable?

easy

A. It uses less memory than unstable sorts

B. It sorts elements in ascending order only

C. It always runs faster than unstable sorts

D. It keeps the original order of equal elements unchanged

Solution

1. Step 1: Understand stability in sorting

   A stable sort means if two elements are equal, their order stays the same as before sorting.

2. Step 2: Compare options with definition

   Only It keeps the original order of equal elements unchanged matches this meaning. Other options describe unrelated properties.

3. Final Answer:

   It keeps the original order of equal elements unchanged -> Option D

4. Quick Check:

   Stable sort = keeps equal elements order [OK]

Hint: Stable means equal items keep their order [OK]

Common Mistakes:

• Confusing stability with sorting order
• Thinking stability means faster sorting
• Assuming stability means less memory use

2. Which Rust standard library method sorts a slice with a stable sort without requiring a comparator closure?

easy

A. slice.sort_unstable_by()

B. slice.sort_unstable()

C. slice.sort()

D. slice.sort_by()

Solution

1. Step 1: Recall Rust slice sorting methods

   Rust's slice.sort() uses a stable sorting algorithm.

2. Step 2: Differentiate stable and unstable methods

   sort_unstable() and sort_unstable_by() are unstable sorts. sort_by() is stable but requires a comparator.

3. Final Answer:

   slice.sort() -> Option C

4. Quick Check:

   slice.sort() = stable sort [OK]

Hint: Use sort() for stable sorting in Rust [OK]

Common Mistakes:

• Choosing sort_unstable() thinking it's stable
• Confusing sort_by() with unstable sort
• Not knowing sort() is stable by default

3. Given the Rust code below, what is the output?

let mut data = [(3, 'a'), (1, 'b'), (3, 'c'), (2, 'd')];
data.sort();
println!("{:?}", data);

medium

A. [(1, 'b'), (2, 'd'), (3, 'a'), (3, 'c')]

B. [(1, 'b'), (2, 'd'), (3, 'c'), (3, 'a')]

C. [(3, 'a'), (3, 'c'), (2, 'd'), (1, 'b')]

D. [(2, 'd'), (1, 'b'), (3, 'a'), (3, 'c')]

Solution

1. Step 1: Understand sorting of tuples in Rust

   Rust sorts tuples by first element, then second if first are equal. Here, sorting by integer first.

2. Step 2: Apply stable sort to keep order of equal keys

   Elements with key 3 are (3, 'a') then (3, 'c'). Stable sort keeps this order.

3. Final Answer:

   [(1, 'b'), (2, 'd'), (3, 'a'), (3, 'c')] -> Option A

4. Quick Check:

   Stable sort keeps (3, 'a') before (3, 'c') [OK]

Hint: Stable sort keeps equal keys in original order [OK]

Common Mistakes:

• Swapping order of equal keys
• Ignoring tuple sorting rules
• Assuming unstable sort by default

4. The following Rust code uses sort_unstable() but the order of equal elements is important. What is the main issue?

let mut items = [(2, 'x'), (1, 'y'), (2, 'z')];
items.sort_unstable();
println!("{:?}", items);

medium

A. The code will not compile because sort_unstable() requires a comparator

B. The order of (2, 'x') and (2, 'z') may change, breaking stability

C. The code will panic at runtime due to unstable sort

D. The output will always be sorted and stable

Solution

1. Step 1: Understand sort_unstable() behavior

   sort_unstable() sorts faster but does not guarantee stable order of equal elements.

2. Step 2: Identify problem with equal keys

   Elements with key 2 may swap order, so (2, 'x') and (2, 'z') order can change, which breaks stability.

3. Final Answer:

   The order of (2, 'x') and (2, 'z') may change, breaking stability -> Option B

4. Quick Check:

   Unstable sort = order of equal keys can change [OK]

Hint: Unstable sort can reorder equal elements [OK]

Common Mistakes:

• Thinking unstable sort always panics
• Assuming unstable sort requires comparator
• Believing unstable sort keeps order

5. You have a list of student records with fields (score: i32, name: &str). You want to sort by score ascending but keep the original order of students with the same score. Which sorting method should you use in Rust and why?

hard

A. Use sort() because it is stable and preserves order of equal scores

B. Use sort_unstable() because it is faster and order doesn't matter

C. Use sort_unstable_by() with a custom comparator for stability

D. Use sort_by() but it is unstable so order may change

Solution

1. Step 1: Identify requirement for stability

   We want to keep original order of students with same score, so stable sort is needed.

2. Step 2: Choose Rust method that is stable

   sort() is stable and sorts ascending by default. sort_unstable() is faster but unstable. sort_unstable_by() is unstable even with comparator. sort_by() is stable but Use sort_by() but it is unstable so order may change claims it is unstable incorrectly.

3. Final Answer:

   Use sort() because it is stable and preserves order of equal scores -> Option A

4. Quick Check:

   Stable sort needed = use sort() [OK]

Hint: Stable sort keeps order of equal keys; use sort() [OK]

Common Mistakes:

• Choosing unstable sort for speed ignoring order
• Thinking sort_unstable_by() is stable
• Misunderstanding sort_by() stability