Search in Rotated Sorted Array in DSA C - Time & Space Complexity
We want to know how fast we can find a number in a rotated sorted array.
How does the search time grow as the array gets bigger?
Analyze the time complexity of the following code snippet.
int search(int* nums, int numsSize, int target) {
int left = 0, right = numsSize - 1;
while (left <= right) {
int mid = left + (right - left) / 2;
if (nums[mid] == target) return 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;
}
}
return -1;
}
This code searches for a target number in a rotated sorted array using a modified binary search.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The while loop that halves the search range each time.
- How many times: The loop runs about log base 2 of the array size times.
Each step cuts the search area roughly in half, so the number of steps grows slowly as the array grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 4 steps |
| 100 | About 7 steps |
| 1000 | About 10 steps |
Pattern observation: Doubling the array size adds only one extra step.
Time Complexity: O(log n)
This means the search time grows slowly, even if the array gets much bigger.
[X] Wrong: "Because the array is rotated, we must check every element, so it takes linear time."
[OK] Correct: The code cleverly uses the sorted parts to still cut the search space in half each time, keeping it fast.
Understanding this search shows you can adapt classic methods to tricky situations, a skill valued in problem solving.
"What if the array was not rotated but had duplicates? How would the time complexity change?"
Practice
Solution
Step 1: Understand sorted vs rotated sorted array
A normal sorted array is fully sorted in ascending order, but a rotated sorted array is a sorted array shifted at some pivot point, breaking the full order.Step 2: Impact on binary search
Binary search requires a fully sorted array to decide which half to search next. In a rotated array, this condition breaks, so normal binary search cannot be directly applied.Final Answer:
The array is not fully sorted, so normal binary search cannot be directly applied -> Option AQuick Check:
Rotated array breaks full sort = normal binary search fails [OK]
- Assuming array is fully sorted
- Ignoring the pivot point
- Thinking duplicates cause the main issue
Solution
Step 1: Understand left sorted portion condition
If the middle element is greater than or equal to the start element, it means mid is in the left sorted portion because left side is sorted ascending.Step 2: Translate condition to code
The condition is written as if (arr[mid] >= arr[start]) in C to check this.Final Answer:
if (arr[mid] >= arr[start]) -> Option BQuick Check:
Mid >= start means left sorted [OK]
- Using <= instead of > or >=
- Comparing mid with end incorrectly
- Confusing left and right sorted parts
int arr[] = {6,7,8,1,2,3,4,5};
int n = 8;
int target = 3;
int start = 0, end = n - 1;
int mid;
while (start <= end) {
mid = (start + end) / 2;
if (arr[mid] == target) {
printf("%d", mid);
break;
}
if (arr[start] <= arr[mid]) {
if (target >= arr[start] && target < arr[mid])
end = mid - 1;
else
start = mid + 1;
} else {
if (target > arr[mid] && target <= arr[end])
start = mid + 1;
else
end = mid - 1;
}
}Solution
Step 1: Trace the binary search on rotated array
Initial array: [6,7,8,1,2,3,4,5], target=3. Start=0, end=7. - mid=(0+7)/2=3, arr[3]=1, not target. - arr[start]=6 > arr[mid]=1, so right half is sorted. - target=3 > arr[mid]=1 and target <= arr[end]=5, so start=mid+1=4. - Now start=4, end=7. - mid=(4+7)/2=5, arr[5]=3 matches target.Step 2: Output the index
Index 5 is printed as the target is found at arr[5].Final Answer:
5 -> Option DQuick Check:
Target 3 found at index 5 [OK]
- Not updating start/end correctly
- Confusing which half is sorted
- Wrong mid calculation
int search(int arr[], int n, int target) {
int start = 0, end = n - 1;
while (start < end) {
int mid = (start + end) / 2;
if (arr[mid] == target) return mid;
if (arr[start] <= arr[mid]) {
if (target >= arr[start] && target < arr[mid])
end = mid - 1;
else
start = mid + 1;
} else {
if (target > arr[mid] && target <= arr[end])
start = mid + 1;
else
end = mid - 1;
}
}
return -1;
}Solution
Step 1: Analyze loop condition impact
The loop uses while (start < end), which misses the case when start == end. This can skip checking the last element, causing incorrect -1 return even if target is present.Step 2: Correct loop condition
Changing to while (start <= end) ensures the last element is checked, preventing missed targets.Final Answer:
The loop condition should be start <= end instead of start < end -> Option CQuick Check:
Loop must include start == end to check all elements [OK]
- Ignoring last element check
- Thinking mid calculation causes bug
- Returning wrong index on failure
Solution
Step 1: Understand duplicates impact on rotated search
Duplicates can cause ambiguity in deciding which half is sorted because arr[start], arr[mid], and arr[end] can be equal, breaking the binary search logic.Step 2: Modify search to handle duplicates
When arr[start] == arr[mid] == arr[end], increment start and decrement end to skip duplicates and continue search safely.Step 3: Avoid linear search or sorting
Linear search is inefficient; sorting changes array and is not allowed. Proper duplicate handling preserves binary search efficiency.Final Answer:
Add extra checks to skip duplicates when arr[start] == arr[mid] == arr[end] -> Option AQuick Check:
Skip duplicates when start=mid=end to continue search [OK]
- Ignoring duplicates cause wrong half detection
- Switching to linear search unnecessarily
- Sorting array before search
Ready to prove it?
Pass the test and this pattern moves unknown
