Overlapping Intervals

For two closed intervals [a,b] and [c,d], they overlap iff a <= d and c <= b. The first condition says the first interval starts no later than the second interval ends. The second says the second interval starts no later than the first interval ends. Both must be true.

This symmetric test is safer than relying on intuition from pictures. [1,3] and [2,6] overlap because 1 <= 6 and 2 <= 3. [1,3] and [4,6] do not overlap because 4 <= 3 is false.

In closed interval problems, [1,3] and [3,5] overlap at the point 3. That means merge logic should use next.start <= current.end. If the prompt says intervals are half-open, then [1,3) and [3,5) are compatible, so the check becomes next.start < current.end.

Before solving, translate the problem statement into one sentence: do intervals that touch conflict? Meeting rooms often say no because one meeting can end exactly when another starts. Merge Intervals often says yes because the endpoint belongs to both ranges.

After sorting by start, adjacent comparison becomes enough for many tasks. If current.start <= next.start, then the condition current.start <= next.end is usually already true for valid intervals. The only remaining question is whether next.start <= current.end.

That is the local comparison behind merge sweeps. Carry [1,6], see [5,7], and overlap because 5 <= 6. Carry [1,6], see [8,10], and stop because 8 <= 6 is false. The sort turns the symmetric formula into a one-sided neighbor test.

The first mistake is using < when the problem expects closed intervals, which leaves [1,3] and [3,5] separated incorrectly. The second is using <= for half-open calendar bookings, which rejects valid back-to-back meetings.

The third mistake is comparing the next interval with the wrong end. In a merge, the carried end may have grown from 3 to 6 after seeing [2,6]. Later intervals must compare against the updated carried end, not the end of the original first interval.