We have two arrays, both already sorted in ascending order, and we need to find the median of their combined elements. The median is the middle value when all elements are arranged in order. If the total number of elements is even, the median is the average of the two middle values.
One approach is to merge the two arrays and pick the middle element, which takes O(m + n) time. The problem asks for O(log(m + n)), which points toward binary search.
Finding the median comes down to finding the correct partition point. If we split the combined elements into a left half and a right half of equal size, where every element in the left half is less than or equal to every element in the right half, then the median comes directly from the elements at the partition boundary. Binary search finds this partition in logarithmic time without merging anything.
0 <= m <= 1000 and 0 <= n <= 1000 -- Either array can be empty. We need to handle the case where one array contributes nothing to the partition.1 <= m + n <= 2000 -- The combined size is at most 2000. Even an O(m + n) merge would be fast enough in practice, but the problem demands O(log(m + n)).-10^6 <= nums1[i], nums2[i] <= 10^6 -- Values fit in a standard integer. No overflow concerns when summing two elements for the average.Since both arrays are sorted, we can merge them into one sorted array using the two-pointer merge technique (the same merge step from merge sort). Once merged, the median is the middle element, or the average of the two middle elements for an even total length.
This does not meet the O(log(m+n)) requirement, but it is a correct baseline that frames the rest of the solutions.
m + n.i and j, starting at the beginning of nums1 and nums2.nums1[i] and nums2[j]. Place the smaller value into the merged array and advance that pointer.This approach builds the entire merged array even though only the middle element or two are needed. The next approach reaches the median position by counting, without storing anything.
We do not need the full merged array. Advancing through both arrays in sorted order until we reach the median position is enough. By counting steps with two pointers, we find the middle element or two in O(m + n) time with O(1) space.
Use two pointers on nums1 and nums2, always advancing the one pointing at the smaller value (the same logic as merging, but without storing anything). Count how many steps have been taken. The values at and just before the median position are the ones we need.
Each iteration picks the next smallest element across the two arrays and assigns it to curr, after copying the old curr into prev. After half + 1 iterations, curr holds the element at position half (0-indexed) of the merged order, and prev holds the element at position half - 1. For an odd total, the median sits at position half, so curr is the answer. For an even total, the two middle positions are half - 1 and half, so the average of prev and curr is the answer.
half = (m + n) / 2.i and j starting at 0 on nums1 and nums2.half + 1 steps, if the total is odd, return the current value. If even, return the average of current and previous.The counting approach removes the extra space but still runs in linear time. Because both arrays are sorted, binary search can locate the correct partition directly instead of stepping to it one element at a time.
The median splits all m + n elements into two equal halves. If we know how many elements to take from nums1 for the left half, the rest must come from nums2. Finding the median reduces to finding the right number of elements to take from one array, and that count can be found with binary search in O(log(min(m, n))).
Take i elements from nums1 and j elements from nums2 for the left half, where i + j = (m + n + 1) / 2. The partition is valid when:
nums1[i-1]) is less than or equal to the smallest element from nums2's right part (nums2[j]).nums2[j-1]) is less than or equal to the smallest element from nums1's right part (nums1[i]).We always binary search on the smaller array to keep the search range minimal and avoid out-of-bounds issues.
The left partition needs exactly half = (m + n + 1) / 2 elements. Choosing i from nums1 forces j = half - i from nums2. Within each array the left part already holds the smaller elements, so the only thing left to verify across arrays is that nums1's left does not exceed nums2's right (maxLeft1 <= minRight2) and nums2's left does not exceed nums1's right (maxLeft2 <= minRight1). When both hold, every left element is less than or equal to every right element, so the boundary values give the median.
Searching only the smaller array keeps j in range [0, n] for every i in [0, m]. If maxLeft1 > minRight2, too many elements came from nums1, so decreasing i is the only way to fix it; the search moves left. If maxLeft2 > minRight1, too few came from nums1, so the search moves right. Each step halves the candidate range for i, which gives O(log(min(m, n))) iterations.
nums1 is the smaller array. If not, swap them.left = 0, right = m (the length of the smaller array).half = (m + n + 1) / 2.left <= right:i = (left + right) / 2 (elements from nums1 in the left half).j = half - i (elements from nums2 in the left half).maxLeft1, minRight1, maxLeft2, minRight2. Use -infinity and +infinity for out-of-bounds.maxLeft1 > minRight2: we took too many from nums1, search left (right = i - 1).maxLeft2 > minRight1: we took too few from nums1, search right (left = i + 1).max(maxLeft1, maxLeft2). For even total: average of max(maxLeft1, maxLeft2) and min(minRight1, minRight2).The partition approach binary searches over an index. A different technique binary searches over the answer value itself. The median is the k-th smallest combined element (or the average of two consecutive k-th smallest elements), so the problem reduces to finding the k-th smallest value across two sorted arrays.
For a candidate value v, the number of combined elements that are less than or equal to v is countLessEqual(nums1, v) + countLessEqual(nums2, v), and each count is itself a binary search inside one sorted array. That total count is non-decreasing as v increases, so we can binary search the value range for the smallest v whose count reaches k. That smallest v is the k-th smallest element.
This is the more general technique. It extends directly to finding the k-th smallest element across any number of sorted arrays, where the partition method does not generalize as cleanly.
kthSmallest(k) as the smallest value v such that at least k combined elements are less than or equal to v.v over the value range [-10^6, 10^6]. For each candidate mid, count elements <= mid in both arrays using a binary search in each.k, the answer is mid or smaller, so move hi = mid. Otherwise move lo = mid + 1.kthSmallest((m + n) / 2 + 1).kthSmallest((m + n) / 2) and kthSmallest((m + n) / 2 + 1).For nums1 = [1, 3] and nums2 = [2], the total is 3 (odd), so the median is the 2nd smallest value, kthSmallest(2). The combined sorted order is 1, 2, 3, so the answer is 2. The value search below is shown narrowed to the data range [1, 3]; the code searches the full range [-10^6, 10^6], which takes a fixed number of iterations regardless of input.
The partition approach (Approach 3) is the one that meets the required O(log(m + n)) bound with O(1) space. The value search trades a tighter bound for a technique that generalizes to k sorted arrays.