Red-Black Trees

AVL's contract — every bf ∈ {−1, 0, +1} — is strict. Strictness buys the shortest possible trees (h ≤ 1.44 log n, superb for searching), but the enforcement is jumpy: modest insertions trigger rotations, and a single deletion can cascade rotations all the way to the root. If your workload modifies the tree constantly — an index ingesting records, a scheduler adding and removing tasks — you pay the enforcement cost on every operation.

Question a lazy engineer would ask: can we relax the balance rule just enough that repairs become rare and cheap, while h stays O(log n)?

Yes: tolerate height up to 2 log(n+1) — about 40% taller than AVL in the worst case — and in exchange, most repairs become recolorings: O(1) paint jobs with no structural change at all. Rotations still exist but fire far less often (insertion: at most 2; deletion: at most 3).

The selection rule you'll be examined on: frequent insertion/deletion → Red-Black wins; search-dominated, rarely-modified data → AVL wins (it's more tightly balanced). That's why library implementers — who can't predict your workload but must survive the worst — almost universally chose Red-Black: std::map, std::set, Java TreeMap, the Linux kernel's scheduler and memory manager.

• 1. Every node is red or black.
• 2. The root is black.
• 3. Every leaf slot (NIL) counts as black.
• 4. A red node's children are black — no two reds in a row on any path.
• 5. Every root-to-NIL path contains the same number of black nodes (the tree's black-height, bh).

Why these force balance: rule 5 says all paths have equal black counts; rule 4 says reds can't stack, so a path can at most alternate black-red-black-red… Therefore the longest path (maximal reds) is at most twice the shortest (all black): h ≤ 2·bh ≤ 2 log₂(n+1). Two local rules, one global guarantee.

Verify rule 5 on any two paths: root→3→NIL crosses blacks {7, 3, NIL} = 3; root→18→10→8→NIL crosses {7, 10, NIL} = 3 (18 and 8 are red, they don't count). Every path: exactly bh = 3. Red nodes are the slack in the system — free vertical space that costs no black-height.

1. BST-insert the key; color it RED
   // red never breaks rule 5 —
   // only possibly rule 4 (red-red)
2. if x is root → paint BLACK, done
3. if parent is BLACK → done (no clash)
4. if parent is RED, look at the UNCLE:
   · uncle RED   → recolor: p → BLACK, u → BLACK,
                            g → RED;
                   x ← g, repeat from 2
   · uncle BLACK → rotate the g–p–x triple
                   (LL/LR/RR/RL, Lecture 8's moves);
                   recolor: new subtree root → BLACK,
                            old grandparent g → RED
                   // same two targets in all four cases —
                   // "new top" black, demoted g red

x is freshly inserted RED. If parent p is black, rules 4 and 5 both hold — done. If p is red, rule 4 is violated (g→p→x, two reds in a row). Since rule 4 held before this insertion, p's parent g must be black — otherwise g-p would already have violated rule 4. So the state is fixed: g black, p red, x red. The uncle u (g's other child) is the only unknown, and its color alone decides which fix is valid.

Rule 4 check: x stays red, but its parent p is now black — no violation at x. g is now red; if g's own parent is red, that is the same violation one level up — hence "x ← g, repeat."

Rule 5 check, by direct count: any path through g into p's subtree contributed g(1)+p(0)=1 black before, and g(0)+p(1)=1 after — identical. Any path through g into u's subtree contributed g(1)+u(0)=1 before, g(0)+u(1)=1 after — identical. Every path's black count through this region is unchanged, because u's count rose by exactly 1 while g's fell by exactly 1 — the cancellation only works because u was red beforehand. No rotation needed; the arithmetic already balances.

Try the Case 1 recolor anyway (u→black is now a no-op, g→red) and check the u-side path: before, g(1)+u(1)=2; after, g(0)+u(1)=1 — that path lost a black unit it had no surplus to give. Rule 5 breaks, because there was no red node on u's side to absorb the change. A pure recolor is asymmetric and invalid whenever u is black.

Fix: rotate, then recolor. Rotate the g–p–x triple (L8's LL/RR/LR/RL moves) so the median of the three keys becomes the new local root; g is demoted to a child. Recolor: new top→black, demoted g→red. Check from above: before, a path entering from g's parent crossed g(1)+p(0)/x(0)=1 black across this whole span; after, it crosses new-top(1)+demoted-g(0)=1 — unchanged. g's original parent sees no difference, so the fix is fully absorbed locally — the loop terminates, it never climbs further.

L7 gave three cases: delete a leaf (unlink it); delete a one-child node (parent adopts the child); delete a two-children node by copying the in-order successor's key up, then deleting the successor from its original spot — which is itself always a leaf or one-child node. So every RB deletion, no matter which case it starts as, bottoms out at physically unlinking one leaf-or-one-child node, y.

The subtlety that matters here: in the two-children case, the key that disappears is the one you asked to delete — but the node that gets physically unlinked, and therefore the color that decides how hard the fix is, belongs to the successor, which can be a completely different color from the key you targeted. Always check the color of y, the node actually removed — never the color of the key you started with.

Delete 5 (RED leaf): unlink it, 10's left becomes NIL directly. Path 20→10→NIL: blacks = {20, 10, NIL} = 3 — unchanged (5 was red, it was never counted). Free, exactly as claimed.

Delete 30 (BLACK leaf): unlink it, 20's right becomes NIL directly. Path 20→NIL: blacks = {20, NIL} = 2 — down from 3, while every other path is still 3. Rule 5 is broken by exactly one black, on exactly this one path. That empty NIL slot is marked double black (DB): a bookkeeping label meaning "this position must count as 2 blacks until the tree is repaired" — not a real color, just a flag tracking the one-black debt while the sibling-based repair (next card) pays it off.