Search in Rotated Sorted Array in DSA Rust - Practice Problems & Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of search in rotated sorted array

What is the output of the following Rust code that searches for a target in a rotated sorted array?

DSA Rust

fn search(nums: Vec<i32>, target: i32) -> i32 {
    let mut left = 0;
    let mut right = nums.len() as i32 - 1;
    while left <= right {
        let mid = left + (right - left) / 2;
        if nums[mid as usize] == target {
            return mid;
        }
        if nums[left as usize] <= nums[mid as usize] {
            if nums[left as usize] <= target && target < nums[mid as usize] {
                right = mid - 1;
            } else {
                left = mid + 1;
            }
        } else {
            if nums[mid as usize] < target && target <= nums[right as usize] {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
    }
    -1
}

fn main() {
    let nums = vec![4,5,6,7,0,1,2];
    let target = 0;
    println!("{}", search(nums, target));
}

A 4

B 0

C -1

D 6

💡 Hint

Think about how the binary search adjusts left and right pointers in a rotated array.

The function returns the index of the target 0 in the rotated sorted array. The target 0 is at index 4.

❓ Predict Output

intermediate

Output when target is not present

What is the output of this Rust code searching for a target not in the rotated sorted array?

DSA Rust

fn search(nums: Vec<i32>, target: i32) -> i32 {
    let mut left = 0;
    let mut right = nums.len() as i32 - 1;
    while left <= right {
        let mid = left + (right - left) / 2;
        if nums[mid as usize] == target {
            return mid;
        }
        if nums[left as usize] <= nums[mid as usize] {
            if nums[left as usize] <= target && target < nums[mid as usize] {
                right = mid - 1;
            } else {
                left = mid + 1;
            }
        } else {
            if nums[mid as usize] < target && target <= nums[right as usize] {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
    }
    -1
}

fn main() {
    let nums = vec![4,5,6,7,0,1,2];
    let target = 3;
    println!("{}", search(nums, target));
}

A 3

B -1

C 0

D 6

💡 Hint

If the target is not found, the function returns -1.

The target 3 is not in the array, so the function returns -1.

🧠 Conceptual

advanced

Why binary search works on rotated sorted arrays

Why can binary search be applied to a rotated sorted array?

A Because the array elements are all unique, so binary search works without modification.

B Because the array is fully sorted, so normal binary search applies directly.

C Because at least one half of the array is always sorted, allowing us to decide which half to search next.

D Because the array is rotated by exactly half its length, making it symmetric.

💡 Hint

Think about the property of the rotated array halves.

In a rotated sorted array, one half is always sorted. This helps decide which half to search next using binary search.

🔧 Debug

advanced

Identify the error in this rotated array search code

What error will this Rust code produce when searching a rotated sorted array?

DSA Rust

fn search(nums: Vec<i32>, target: i32) -> i32 {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left <= right {
        let mid = (left + right) / 2;
        if nums[mid] == target {
            return mid as i32;
        }
        if nums[left] <= nums[mid] {
            if nums[left] <= target && target < nums[mid] {
                right = mid - 1;
            } else {
                left = mid + 1;
            }
        } else {
            if nums[mid] < target && target <= nums[right] {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
    }
    -1
}

fn main() {
    let nums = vec![4,5,6,7,0,1,2];
    let target = 0;
    println!("{}", search(nums, target));
}

A Infinite loop because left and right pointers never update

B Prints -1 because target is not found

C Compilation error due to type mismatch

D Panic due to unsigned integer underflow when right becomes negative

💡 Hint

Check how right is declared and updated.

The variable right is usize (unsigned). When mid is 0 and right = mid - 1, it underflows causing panic.

🚀 Application

expert

Find minimum element index in rotated sorted array

Given a rotated sorted array with no duplicates, which Rust code correctly returns the index of the minimum element?

A

fn find_min_index(nums: Vec<i32>) -> usize {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left < right {
        let mid = left + (right - left) / 2;
        if nums[mid] > nums[right] {
            left = mid + 1;
        } else {
            right = mid;
        }
    }
    left
}

B

fn find_min_index(nums: Vec<i32>) -> usize {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left <= right {
        let mid = (left + right) / 2;
        if nums[mid] < nums[left] {
            right = mid - 1;
        } else {
            left = mid + 1;
        }
    }
    right
}

C

fn find_min_index(nums: Vec<i32>) -> usize {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left < right {
        let mid = (left + right) / 2;
        if nums[mid] < nums[left] {
            right = mid;
        } else {
            left = mid + 1;
        }
    }
    left
}

D

fn find_min_index(nums: Vec<i32>) -> usize {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left < right {
        let mid = left + (right - left) / 2;
        if nums[mid] >= nums[left] {
            left = mid + 1;
        } else {
            right = mid;
        }
    }
    right
}

💡 Hint

The minimum element is the only element where the previous element is greater or it is the smallest in the right half.

Option A correctly uses binary search to find the minimum by comparing mid and right elements, narrowing the search space until left == right.

Practice

1. What is the main challenge when searching for a target in a rotated sorted array compared to a normal sorted array?

easy

A. The array size is unknown

B. The array contains duplicate elements

C. The array is sorted in descending order

D. The array is split into two sorted parts, making direct binary search tricky

Solution

1. Step 1: Understand the array structure

   A rotated sorted array is originally sorted but then rotated at some pivot, splitting it into two sorted parts.

2. Step 2: Impact on search

   This split means a normal binary search can't be applied directly because the order is disrupted at the pivot.

3. Final Answer:

   The array is split into two sorted parts, making direct binary search tricky -> Option D

4. Quick Check:

   Rotated array = two sorted parts [OK]

Hint: Look for the pivot splitting the array into two sorted halves [OK]

Common Mistakes:

• Assuming the array is fully sorted without rotation
• Ignoring the pivot point in the array
• Thinking duplicates cause the main challenge
• Confusing descending order with rotation

2. Which Rust code snippet correctly declares a function signature to search a target in a rotated sorted array?

easy

A. fn search(nums: &[i32], target: i32) -> Option<usize>

B. fn search(nums: Vec<i32>, target: i32) -> usize

C. fn search(nums: &Vec<i32>, target: i32) -> bool

D. fn search(nums: &[i32], target: i32) -> i32

Solution

1. Step 1: Analyze parameter types

   Using a slice &[i32] is efficient and idiomatic for read-only array input in Rust.

2. Step 2: Analyze return type

   Returning Option<usize> allows indicating if the target was found (Some(index)) or not (None).

3. Final Answer:

   fn search(nums: &[i32], target: i32) -> Option<usize> -> Option A

4. Quick Check:

   Slice input + Option return = fn search(nums: &[i32], target: i32) -> Option<usize> [OK]

Hint: Use &[i32] for input and Option<usize> for index result [OK]

Common Mistakes:

• Using Vec<i32> unnecessarily copies data
• Returning usize without Option loses 'not found' info
• Returning bool loses index information
• Returning i32 index can be ambiguous

3. Given the Rust function below, what is the output when searching for target 3?

fn search(nums: &[i32], target: i32) -> Option<usize> {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left <= right {
        let mid = (left + right) / 2;
        if nums[mid] == target {
            return Some(mid);
        }
        if nums[left] <= nums[mid] {
            if nums[left] <= target && target < nums[mid] {
                right = mid - 1;
            } else {
                left = mid + 1;
            }
        } else {
            if nums[mid] < target && target <= nums[right] {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
    }
    None
}

let arr = [4,5,6,7,0,1,2];
println!("{:?}", search(&arr, 3));

medium

A. None

B. Some(2)

C. Some(4)

D. Some(0)

Solution

1. Step 1: Understand the array and target

   The array is [4,5,6,7,0,1,2], target is 3 which is not present in the array.

2. Step 2: Trace the search logic

   The function performs binary search on rotated array but since 3 is missing, the loop ends returning None.

3. Final Answer:

   None -> Option A

4. Quick Check:

   3 not in array = None [OK]

Hint: If target missing, function returns None [OK]

Common Mistakes:

• Assuming target 3 is present and returning wrong index
• Confusing mid calculation causing infinite loop
• Ignoring rotation logic in conditions
• Returning Some with wrong index

4. Identify the bug in the following Rust code for searching a target in a rotated sorted array:

fn search(nums: &[i32], target: i32) -> Option<usize> {
    let mut left = 0;
    let mut right = nums.len() - 1;
    while left < right {
        let mid = (left + right) / 2;
        if nums[mid] == target {
            return Some(mid);
        }
        if nums[left] <= nums[mid] {
            if nums[left] <= target && target < nums[mid] {
                right = mid - 1;
            } else {
                left = mid + 1;
            }
        } else {
            if nums[mid] < target && target <= nums[right] {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
    }
    None
}

medium

A. The function should return bool instead of Option<usize>

B. The mid calculation should use floating division

C. The loop condition should be while left <= right, not while left < right

D. The array should be mutable

Solution

1. Step 1: Analyze loop condition

   The loop uses while left < right, which misses checking when left == right, possibly skipping the last element.

2. Step 2: Correct loop condition

   Changing to while left <= right ensures all elements are checked, including when left equals right.

3. Final Answer:

   The loop condition should be while left <= right, not while left < right -> Option C

4. Quick Check:

   Loop must cover all indices [OK]

Hint: Use while left <= right to cover all elements [OK]

Common Mistakes:

• Using < instead of <= causing missed checks
• Trying floating division for mid index
• Changing return type unnecessarily
• Making array mutable without need

5. You have a rotated sorted array with possible duplicates: [2,2,2,3,4,2]. How would you modify the search algorithm to correctly find target 3?

hard

A. Sort the array before searching

B. Add extra checks to skip duplicates when nums[left] == nums[mid] == nums[right]

C. Use linear search instead of binary search

D. Ignore duplicates and apply normal rotated search

Solution

1. Step 1: Understand duplicates impact

   Duplicates can make it unclear which side is sorted because nums[left], nums[mid], nums[right] may be equal.

2. Step 2: Modify algorithm to skip duplicates

   When nums[left] == nums[mid] == nums[right], increment left and decrement right to skip duplicates and continue search.

3. Step 3: Avoid sorting or linear search

   Sorting changes array order; linear search is inefficient. Proper duplicate handling keeps binary search efficient.

4. Final Answer:

   Add extra checks to skip duplicates when nums[left] == nums[mid] == nums[right] -> Option B

5. Quick Check:

   Skip duplicates to maintain binary search [OK]

Hint: Skip duplicates at edges when equal to mid [OK]

Common Mistakes:

• Sorting array losing rotation info
• Using linear search losing efficiency
• Ignoring duplicates causing wrong results
• Assuming duplicates don't affect logic