PrepStack · Markdown HTML

Interval sorting greedy

Greedy and scheduling · HTML

Formal shape

For half-open I=[s,e), selection variants often sort by e and accept when s>=last_end. Merge and cover variants usually sort by s and maintain a farthest end. The objective determines both endpoint semantics and sort key.

Recognition signals

False friends

SignalWhy it is different
Weighted interval selectionEarliest finish need not maximize total value; use DP with predecessor lookup.
An arbitrary conflict graphWhen conflict is not interval intersection, one endpoint cannot summarize future feasibility.
Dynamic insertion and deletionA one-time sorted scan does not maintain an online set; use an ordered or range structure.

Core invariant

Among solutions with the same number of selections from the processed prefix, the greedy one has a finish boundary no later than any replacement and therefore leaves maximal future room.

State, transition, and processing order

ItemDefinition
StateSorted intervals, last_end, and the answer; coverage variants may instead track current_end and farthest.
TransitionAccept a compatible interval and update the boundary. On conflict, retain the alternative that constrains the future least, usually the earlier finish.
Frontier / orderThe endpoint order dictated by the proof: typically finish order for selection and start order for merge or coverage.

Python skeleton

def max_compatible(intervals):
    # Half-open intervals [start, end).
    ordered = sorted(intervals, key=lambda p: (p[1], p[0]))
    chosen = []
    last_end = float('-inf')
    for start, end in ordered:
        if start >= last_end:
            chosen.append((start, end))
            last_end = end
    return chosen

Correctness sketch

  1. Let g be the feasible interval with earliest finish and o the first interval of an optimum; end(g)<=end(o).
  2. Replacing o with g preserves every later feasible interval and the selected count.
  3. After removing the prefix covered by g, the remainder is the same problem; repeated exchanges produce the greedy optimum.

Complexity

TimeSpaceParameters
O(n log n), with an O(n) scanO(n) for copied order/output; potentially less in placen is interval count; endpoint closure changes compatibility.

Edge cases

Error patterns

PatternWhy it fails / fix
Guessing the sort keyCompatibility selection and merging need different orders; derive the key from the invariant.
Off-by-one endpoint logicHalf-open intervals allow >=; closed intervals may require >. State the model first.
Applying an unweighted proof to valuesThe exchange preserves cardinality, not unequal rewards.
Keeping the later finishThat consumes more future space and reverses the selection invariant.

Selection and exclusion rules

RelationTemplateBoundary
instanceExchange-argument greedy orderingThe earliest-finish rule is proved by replacing an optimum's first interval.
alternative-viewSweep line with sorted eventsMeasuring concurrency, overlap depth, or an active set.

Original micro-example

PartDetail
ResultTwo slots survive, and [1,2) leaves more future room than [0,3).
SetupAvailable slots are [0,3), [1,2), [2,5), and [4,6).
TraceFinish order selects [1,2), then [2,5); the other intervals conflict with the current boundary.

Recall prompts

My notes