Binomial Heaps

A regional disaster strikes. Hospital A's emergency queue and Hospital B's emergency queue — each already a valid, fully-built priority queue with hundreds of waiting patients — must become one single queue, right now, so a combined response team can serve strictly by urgency. Neither hospital has time to rebuild a queue from scratch.

Lecture 16's binary heap has no efficient UNION. The only way to combine two binary heaps is to concatenate their arrays and re-run BUILD-MAX-HEAP (or BUILD-MIN-HEAP) from scratch — Θ(n), where n is the combined size. For two mid-sized hospitals, that could mean re-heapifying thousands of records during the exact moment speed matters most.

Every column reads k straight off the tree — nodes 2^k, height k, root children k. Spot any one and you know which tree you are looking at.

• Not a binary tree. The root of B₃ has three children, and nothing limits a node to two. Binomial trees are general trees — that surprise catches people who arrive straight from Lecture 16.
• Not a heap by itself. B_k is only a shape. The heap ordering (every parent ≤ its children) is an extra condition laid on top, which is what makes it a binomial heap later in L18·04.

You now know what B_k looks like and how one is built. The next slide writes that same rule down formally and works out what follows from it.

B₀ is a single node. B_k is formed by taking two copies of B_k-1 and linking them: the root of one becomes the new leftmost child of the root of the other. That's the entire definition — every other property falls out of it.

• B_k has exactly 2^k nodes (two copies of a 2^k-1-node tree).
• B_k has height exactly k.
• B_k has exactly C(k,i) nodes at depth i — the binomial coefficients, which is exactly where the name comes from.
• The root of B_k has degree k, and — left to right — its children are the roots of B_k-1, B_k-2, …, B₀.

• Min-heap-ordered: every binomial tree in the heap obeys the min-heap property — a node's key is never less than its parent's.
• At most one tree per degree: for any k, the heap contains at most one B_k.

Write n in binary. Bit i is 1 exactly when the heap contains a B_i. A heap of 13 patients (binary 1101) is a B₃ (8 nodes) + a B₂ (4 nodes) + a B₀ (1 node) — never two trees of the same degree, exactly like a binary digit is never anything but 0 or 1.

Five fields, fixed size, forever. A root with 20 children still stores exactly one child pointer — the other 19 are reached by hopping along sibling.

y = x.child
while y ≠ NIL:
    visit y
    y = y.sibling

Compare with Lecture 16, where the same job was A[2i] and A[2i+1] — two array reads, no pointer chasing. This is the concrete cost of giving up the single complete tree: more memory per node, and worse cache locality.

This is not an inconsistency — each ordering is chosen for the operation that depends on it, as below.

Each direction is chosen for the one operation that depends on it: the increasing root list is what lets UNION run in a single linear pass, and the decreasing child list is what lets EXTRACT-MIN hand back a legal heap without any repair work. Both are worth seeing drawn out — that is the next slide.

Removing the root of a B₃ leaves 8 − 1 = 7 nodes, and the leftovers are B₂ + B₁ + B₀ = 4 + 2 + 1 = 7. ✓

In binary, 7 = 111 — every bit set. That is not a coincidence: 2^k − 1 is always k ones, which says the leftovers must be exactly one tree of every order from k−1 down to 0. This is the same "no gaps inside a tree" property from L18·02a, seen from the other side — and it is precisely why the leftovers are always a valid heap.

You will watch both of these run for real: the merge-and-carry sweep in L18·06, and the detach-reverse-union in L18·08.

Arrivals 7, then 8, then 4. Same story: 7 and 8 collide at degree 0 and link (7 ≤ 8, so 7 takes the root), then 4 finds the degree-0 slot empty and simply joins the root list. Three patients, binary 11.

These two queues — Hospital A and Hospital B — are precisely the two inputs merged on the next slide.

Read the binary column downward: 0, 1, 10, 11 — a counter incrementing. A carry in the counter is a link in the heap, and the two happen at exactly the same moments. L18·07 pushes this further with a triple cascade.

DECREASE-KEY(H, x, k)
  if k > x.key: error
  x.key = k
  y = x;  z = y.parent
  while z ≠ NIL and y.key < z.key:
      swap y.key ↔ z.key
      y = z;  z = y.parent

• Keys move, nodes do not. Only key fields are swapped — every child, sibling and degree is untouched, so the tree stays a valid B₃ and the root list never changes.
• The loop is bounded by height. It walks x up to its root, and a B_k has height k ≤ ⌊lg n⌋ — so at most O(log n) swaps. That is the "sift-up path" the complexity table refers to.
• This is what parent is for. It is the only operation in this lecture that travels upward; L18·04a's fifth pointer field finally earns its place.

1. How do you find x in the first place?

You do not search for it — that would be O(n) and would wreck the bound. DECREASE-KEY takes a pointer to the node. Real users keep a handle: Dijkstra and Prim hold a vertex → node array, so relaxing an edge jumps straight to the right node.

2. What about DELETE?

It reuses what you already have — no new machinery:

DELETE(H, x)
  DECREASE-KEY(H, x, −∞)
  EXTRACT-MIN(H)

Drive the key below every other key and it sifts all the way to the root of its tree; being the minimum, EXTRACT-MIN then removes it. Two O(log n) steps, so DELETE is O(log n) as well.

• UNION in O(log n) — the headline improvement over a binary heap's Θ(n), verified today on two real 3-node heaps.
• Every other core operation (INSERT, MINIMUM, EXTRACT-MIN, DECREASE-KEY, DELETE) still runs in O(log n) or better — no regression versus a binary heap.
• A genuinely clean mental model: a binomial heap behaves exactly like a binary counter — INSERT is "add 1," UNION is "binary addition," carries and all.
• INSERT is O(log n) worst case but O(1) amortized — most insertions cause zero cascading links, exactly like most binary-counter increments flip only the lowest bit.

• More overhead per node. Parent/child/sibling/degree pointers cost real memory, versus a binary heap's implicit array indices — and pointer-chasing is less cache-friendly than sequential array access.
• More complex to implement correctly. The four linking cases in UNION (Lecture 18's own flagship animation) are meaningfully trickier than a binary heap's single sift-up/sift-down rule.
• No benefit if you never need UNION. A plain binary heap remains simpler, more cache-friendly, and equally fast for insert/extract-min alone — don't reach for a binomial heap unless merging is actually part of your workload.
• Still not the best at DECREASE-KEY-heavy workloads (e.g. Dijkstra's algorithm with many edge relaxations) — Lecture 19's Fibonacci heap improves exactly that operation, from O(log n) to O(1) amortized.

Combining two independently-run triage queues — hospitals, disaster-response teams, or field units — into one, fast, without ever rebuilding from scratch.

When two compute clusters or worker pools are consolidated (auto-scaling merges, data-center failover), their pending-job priority queues need to become one queue without an expensive full re-sort.

A classic MST algorithm variant maintains one edge-priority-queue per connected component and repeatedly extracts the cheapest edge; whenever two components merge, their two queues must merge too — exactly a binomial-heap UNION, once per merge.

Large distributed simulations run independent event queues per node; periodically synchronizing (merging) them into a global queue benefits directly from fast UNION.

Systems that maintain ordered pending-operation queues on independent replicas, then merge after a network partition heals, face the same "combine two already-valid structures cheaply" problem.

Regional game servers merging after a scheduled maintenance window need to combine independent priority-ranked matchmaking queues into one.