Segment Trees & Interval Trees

Suppose n machines are each busy during some integer time interval — machine A from minute 15 to 20, machine B from 10 to 30, and so on. A scheduler constantly asks: "which machines are busy during minute [2,3]?" — a single point (or unit interval) "stabbing" through a set of ranges.

A plain BST indexes single values, not ranges — it has no natural notion of "does my point fall inside this stored interval?" Scanning all n intervals per query is O(n). With thousands of intervals and thousands of queries, that's too slow.

• IP router filters: a firewall rule like (10*, [20,60]) matches a rectangle of address space — deciding which rules match a packet is a stabbing query.
• VLSI mask verification / motion tracking: computational geometry problems reduce to "which segments does this sweep-line touch right now?"
• Genome / calendar / network-event systems: "which recorded intervals overlap this instant?" — the same question, different domain.

A segment tree answers this in O(log n + k), where k is the number of intervals reported — by pre-organizing the integer universe itself, once, into a fixed hierarchy of ranges.

• Every node v represents a closed range [s(v), e(v)] with s(v) < e(v), both integers.
• The root represents the whole universe, [1, n].
• If e(v) = s(v) + 1, v is a leaf — a unit interval, [k, k+1]. It splits no further.
• Otherwise, split at the midpoint m = ⌊(s(v)+e(v))/2⌋: left child = [s(v), m], right child = [m, e(v)].

Notice what's fixed before you insert a single interval: the entire tree shape depends only on the universe size n — not on which intervals you'll eventually store. You build the skeleton once; then you decorate nodes of that skeleton with whichever intervals fall inside them. This is completely different from a BST, where the shape depends on the data itself.

n = 13 is not a power of 2, so the tree isn't perfectly complete — some branches hit unit length one level sooner than others. That's normal and doesn't break anything: the height bound ⌈log₂12⌉ + 1 = 5 still holds everywhere.

Teal boxes still have children (they split further). Amber boxes are leaves — unit intervals, done splitting. Watch the tree reveal one full level at a time.

insert(s, e, v):
  // store [s,e] into the subtree rooted at v
  if s <= s(v) and e(v) <= e:
      add [s,e] to v            // v's whole range fits inside [s,e]
      // stop — do NOT recurse into v's children
  else:
      m = (s(v) + e(v)) / 2
      if s < m:  insert(s, e, v.left)
      if e > m:  insert(s, e, v.right)

• If [i,j] is stored at node v, it is never also stored at any ancestor or sibling of v — no duplication, no double-reporting.
• At any single level of the tree, [i,j] is stored in at most 2 nodes.
• Since the tree has O(log n) levels, every interval is stored in O(log n) nodes total — this set of nodes is called its canonical decomposition.

A unit interval like [5,6] corresponds to exactly one leaf, and a tree has exactly one path from root to any leaf. Any interval whose canonical decomposition includes a node on that path necessarily overlaps [5,6] — and by the "no duplication" property, nothing is ever reported twice.

Both [3,11] (Machine A) and [4,10] (Machine B) happen to be canonically stored at node [4,7] — which sits directly on the path to leaf [5,6]. So this single query should report both machines as busy at minute 5, from that one stop, and nothing else.

A segment tree needs the whole integer range known in advance — build once over [1,n], then insert intervals into it. But real scheduling data rarely looks like that: meeting times are real-valued and span years; genome coordinates run into the billions; network events arrive with no known upper bound. Rebuilding a segment tree's skeleton every time the universe changes is wasteful, or simply impossible if it's unbounded.

Stop indexing the number line. Index the intervals themselves, directly, the way a BST indexes keys — ordered by their low endpoint — and augment every node with one extra number: the largest high endpoint anywhere in its subtree. That single number is enough to search, insert, and delete in O(log n), fully dynamically, with no universe size fixed in advance.

Real uses: calendar/meeting-room scheduling, overlapping-gene detection in genome analysis, network event simulation.

• Its own interval, [low, high].
• max — the largest high endpoint anywhere in the subtree rooted here (itself included).

BST ordering is by low value only. The underlying tree can be a plain BST, or a self-balancing one — we'll use an AVL tree (Lectures 7–9) as the skeleton, since you've already mastered its rotations. The genuinely new machinery today is the max augmentation, not rebalancing.

Intervals [a,b] and [c,d] overlap exactly when a ≤ d and c ≤ b — equivalently, "neither one ends before the other begins."

Overlapping: 5 ≤ 20 and 10 ≤ 15 — both hold.

Not overlapping: 3 ≤ 20 holds, but 13 ≤ 9 fails — [3,9] ends before [13,20] begins.

1. Descend by comparing low values, exactly like an ordinary BST insert.
2. Place the new node as a leaf; its own max starts equal to its own high.
3. Walk back up the same path to the root, and at every ancestor recompute max = the largest of: its own high, its left child's max (if any), its right child's max (if any).

Most of the max-update steps below will report no change — the new value simply wasn't the largest one already known at that ancestor. That's just as important to see as the steps where max does change: it's the reason this update only ever costs O(depth), never more.

findOverlaps(v, i):
  if v is null: return
  if overlap(v.interval, i): report v.interval
  if v.left exists and v.left.max >= low(i):
      findOverlaps(v.left, i)
  if v.right exists and low(v) <= high(i):
      findOverlaps(v.right, i)

v.left.max is the largest high endpoint anywhere in the left subtree. If even that largest value is smaller than low(i), nothing in the left subtree can overlap i — skip it entirely, without visiting a single node inside it. That's the entire payoff of the max augmentation.

query [5,6] asked: "who's busy at this one instant — minute 5?" A single point in time. The answer is whichever machines happen to be running right then, and only them.

findOverlaps(root, [14,16]) asks something broader: "who's busy at any point during this whole 2-minute window?" Not an instant — a span. A machine doesn't need to be running for the whole window, or even most of it — sharing a single minute with the query is enough to count.