Last Updated: March 29, 2026
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.
The straightforward approach would be to merge the two arrays and pick the middle element. That's O(m + n) time. But the problem explicitly asks for O(log(m + n)), which is a strong hint that we need binary search.
The key observation is this: finding the median is really about finding the correct partition point. If we can 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 lets us find this partition in logarithmic time without actually 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.The most natural approach: since both arrays are sorted, merge them into one sorted array using the two-pointer merge technique (the same merge step from merge sort). Once merged, the median is just the middle element (or the average of the two middle elements for even-length arrays).
This doesn't meet the O(log(m+n)) requirement, but it's an important starting point. It verifies your understanding of the problem and gives you a correct baseline to compare against.
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 works correctly but merges the entire arrays even though we only need the middle element(s). What if we counted our way to the median position without storing the full merge?
We don't actually need the full merged array. We just need to advance through both arrays in sorted order until we reach the median position. By counting steps with two pointers, we can find the middle element(s) in O(m + n) time with O(1) space.
The idea is simple: use two pointers on nums1 and nums2, always advancing the one pointing at the smaller value (same logic as merging, but without storing anything). Count how many steps we've taken. When we reach the median position, record that value.
We're simulating the merge without storing it. Each iteration picks the next smallest element from the two arrays, but instead of writing it to an array, we just update two tracking variables: prev and curr. After advancing half + 1 times, curr holds the element at position half (0-indexed), and prev holds the element at position half - 1. These are exactly the one or two values we need for the median.
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 eliminates extra space but is still linear. Since both arrays are sorted, can we binary search for the correct partition instead of walking to it one element at a time?
Here's the core insight that makes O(log(min(m, n))) possible. 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. So finding the median reduces to finding the right number of elements to take from one array.
Let's say we 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 median requires exactly half = (m + n + 1) / 2 elements in the left partition. If we choose i elements from nums1, we must take j = half - i from nums2. The partition is correct when the cross-conditions hold: the largest element on the left side of one array doesn't exceed the smallest element on the right side of the other.
By always searching on the smaller array, i ranges from 0 to m, and j is always valid (between 0 and n). If the partition has too many from nums1 (maxLeft1 > minRight2), we decrease i. If too few (maxLeft2 > minRight1), we increase i. Since i is bounded by [0, m] and we're binary searching, convergence is guaranteed in O(log(min(m, n))).
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).