Binary Heaps & Heap Operations

A collection keeps changing — items are added, and repeatedly you need to pull out the current maximum (or minimum), never a specific key, never the full sorted order. Job schedulers, event simulators, and Lecture 6's Huffman-code builder all have exactly this shape: "give me the most/least urgent item right now."

• Unsorted array: insert is O(1), but finding the max means scanning everything — O(n) every single extraction.
• Sorted array: extracting the max is O(1) (just take the end), but inserting means shifting elements to keep it sorted — O(n) every insertion.
• Balanced BST (Lecture 7–9): O(log n) for both — but it's a much bigger hammer than this job needs: pointers, rotations, and full ordering support you never asked for, just to repeatedly find an extreme value.

• Shape property: the tree is a complete binary tree — every level is completely filled except possibly the last, which fills left to right with no gaps.
• Max-heap property: for every node i (except the root), A[PARENT(i)] ≥ A[i]. The maximum is always at the root.
• Min-heap property (the mirror image): A[PARENT(i)] ≤ A[i] everywhere — the minimum is always at the root. Everything today works identically for min-heaps; we'll build max-heaps throughout.

Because the shape is always a complete tree, position alone determines structure. Store the tree in an array A, 1-indexed, level by level, left to right:

Every animation today shows the array and the tree side by side — they are the same object, just two views of it.

• O(1) peek at the max (or min) — it's always the root.
• O(log n) insert and O(log n) extract-max — matching a balanced BST with far simpler code.
• O(n) build from an arbitrary array — a genuinely surprising tight bound we'll prove today, not the loose O(n log n) you'd guess from "n calls, each O(log n)."
• Pure array storage — no pointers, no per-node overhead, excellent cache locality.

• No efficient arbitrary search. The heap property only relates a node to its parent — it says nothing about left vs. right siblings or across subtrees. Finding "is key 7 in this heap?" is O(n), not O(log n).
• No efficient decrease-key/increase-key without an auxiliary index map to locate a given key inside the array first. This exact limitation is what motivates Fibonacci heaps (Lecture 19) for algorithms like Dijkstra's shortest path that decrease-key constantly.
• No efficient merge of two heaps — combining two binary heaps means an O(n) rebuild. This motivates Binomial and Pairing heaps (Lectures 18 and 20), built specifically to merge quickly.
• Heap order ≠ sorted order. Reading the array top to bottom does not give you sorted output — that takes repeated extraction, which is exactly what Lecture 17's Heap Sort does.

MAX-HEAPIFY(A, i, n):
    l = 2i          // left child
    r = 2i + 1      // right child
    largest = i

    if l ≤ n and A[l] > A[largest]:
        largest = l
    if r ≤ n and A[r] > A[largest]:
        largest = r

    if largest ≠ i:
        swap A[i] ↔ A[largest]
        MAX-HEAPIFY(A, largest, n)

The precondition matters: the subtrees rooted at 2i and 2i+1 must already be valid heaps. Only A[i] may be out of place. The job is to float that one value down to where it belongs — and the final recursive call is exactly that: having swapped it one level down, follow it and check again.

BUILD-MAX-HEAP(A, n):
    for i = ⌊n/2⌋ downto 1:
        MAX-HEAPIFY(A, i, n)

That's the entire algorithm — three lines. Two questions it immediately raises, and both are answered by the precondition above:

• Why start at ⌊n/2⌋? Every index past ⌊n/2⌋ is a leaf, and a lone node is already a valid heap. For n = 10 that means indices 6…10 are skipped outright — half the array, for free.
• Why count downwards? MAX-HEAPIFY(A, i) is only allowed to run once i's children are already heaps. Going bottom-up guarantees exactly that: by the time you reach i, everything beneath it has been fixed.

Take the array from the next slide, A = [4, 1, 3, 2, 16, 9, 10, 14, 8, 7], and run the very first call, MAX-HEAPIFY(A, 5):

• i = 5, so l = 10, r = 11. A[5] = 16.
• l = 10 ≤ 10 and A[10] = 7 > 16? No — largest stays 5.
• r = 11 ≤ 10? No, past the end — skipped.
• largest = i, so no swap, no recursion. 16 was already bigger than its only child.

That "nothing happened" case is a real step in the animation, not a skipped one — it is exactly what the if largest ≠ i test is there to detect.

MAX-HEAPIFY follows one root-to-leaf path in the worst case, doing a constant amount of work per level → O(log n).

BUILD-MAX-HEAP makes n/2 such calls, so the obvious bound is O(n log n) — but that is loose. Most of those calls are on short subtrees near the bottom, and the true total is O(n). L16·05 does that summation properly; for now, just notice while watching that the early calls barely move anything, and only the last few travel far.

"n calls to MAX-HEAPIFY, each costing O(log n)" gives O(n log n). This is a valid upper bound — but it's not tight, because it assumes every node sits near the top of the tree, costing a full O(log n). Most nodes don't.

MAX-HEAPIFY on a node of height h costs O(h) — and a heap of n nodes has at most ⌈n/2^h+1⌉ nodes at height h. So total cost is bounded by:

The sum ∑ h/2^h converges to a constant (2) regardless of n — most nodes are near the bottom (cheap, O(1)-ish), and only a few are near the top (expensive, O(log n)), and that trade-off exactly cancels out to linear total work.

The classic Huffman algorithm repeatedly extracts the two lowest-frequency nodes and reinserts their merged parent — exactly the extract-min / insert cycle we animated today, run n−1 times, backed by a min-priority queue.

Lecture 5's tournament trees solved the same underlying problem — repeatedly identify the current minimum across many runs — for merge and replacement selection. A binary heap is the in-memory, array-based cousin of that same repeated-extract-min idea.

BUILD-MAX-HEAP once, then repeatedly swap the root with the last element and MAX-HEAPIFY the shrinking heap — an in-place O(n log n) sort using nothing we haven't already built today. Full treatment in Lecture 17.

Operating-system schedulers and discrete-event simulators use a priority queue keyed on deadline or timestamp — "run the most urgent job next" is the priority-queue problem, verbatim.

Dijkstra's shortest-path and Prim's minimum-spanning-tree algorithms both repeatedly pick the cheapest available edge/vertex — the standard implementation uses a binary heap as the priority queue, upgraded to a Fibonacci heap (Lecture 19) when decrease-key dominates.

A pair of heaps (one max-heap for the lower half, one min-heap for the upper half) maintains a running median in O(log n) per insertion — a common interview and streaming-data pattern.