Pairing Heaps & Double-Ended Priority Queues

Lecture 19 ended with a caveat: Fibonacci heaps win the asymptotic argument for Dijkstra's algorithm, but the parent/child/left/right/degree/mark bookkeeping per node, plus cascading-cut logic, carries real constant-factor cost. An engineer actually shipping a routing engine or a game-AI pathfinder needs something that wins in practice, at the graph sizes that really show up — not just in the limit as n → ∞.

Pairing heaps were invented specifically to answer this. Experimentally, they are consistently faster than Fibonacci heaps in practice, simpler to implement correctly, carry smaller runtime overhead per operation, and use less memory per node — no degree field, no mark bit, no parent pointer at all.

• A pairing heap is a single min-heap-ordered tree — not a forest like binomial or Fibonacci heaps. Every node's key is ≤ every key in its subtree.
• Children are unordered and held in a doubly-linked sibling list (not circular, unlike Fibonacci heaps' root/child lists).
• Each node stores exactly three pointers: child (its first child), left and right (siblings) — plus its key. That is the entire node.

A node x is the first child in its sibling list exactly when x.left.child = x. So instead of wasting a slot on a separate parent pointer, the left pointer of a first child is simply repurposed to point at the parent — and every other sibling's left points at its left neighbour as usual.

This one trick is what makes DECREASE-KEY and REMOVE cheap without any cascading-cut bookkeeping: you can always find "where does this node detach from" in O(1), using only left/right — no degree or mark field is ever needed.

Given two pairing-heap trees, MELD compares their roots. The tree rooted at the larger key becomes the new leftmost child of the tree rooted at the smaller key — one pointer rewire, no traversal of either tree's interior. Every other operation in this lecture — INSERT, DECREASE-KEY, REMOVE-MIN, REMOVE — is built entirely out of calls to MELD.

Tree 1: root 5, child [9]. Tree 2: root 3, children [8, 6].

• Every core operation reduces to MELD, an O(1) actual-cost primitive — the whole implementation is short and hard to get subtly wrong.
• Smaller node footprint than Fibonacci heaps: 3 pointers + a key (4 fields total), versus 4 pointers + a key + degree + mark (7 fields total).
• Experimentally faster than Fibonacci heaps across realistic workloads — better cache behaviour, fewer pointer chases per operation.
• INSERT and MELD are O(1) actual cost — both are single MELD calls.

• REMOVE-MIN needs a good multi-way-meld strategy. Melding the orphaned children left-to-right in a naive chain gives Θ(n) amortized cost — genuinely bad. The two-pass and multipass schemes fix this to O(log n) amortized, but you must implement one of them correctly.
• DECREASE-KEY's tight amortized bound is a famous open problem. It is conjectured to be O(1) amortized (matching Fibonacci heaps) and performs like it in practice, but the best proven upper bound is more subtle, and a matching lower bound rules out a naive O(1) proof via the obvious potential function.
• Worst-case degree and height are both Θ(n) for a single operation sequence (e.g. inserting keys in sorted order) — exactly like a Fibonacci heap tree can look, before any consolidation.

The "bad way": currentTree = compareLink(currentTree, nextTree) repeated left to right. If you alternate n/2 inserts then n/2 remove-mins in the worst order, the total remove-min cost becomes (n/2−1)+…+2+1+0 = Θ(n²) — if insert is O(1) amortized, that forces remove-min to be Θ(n) amortized. Genuinely bad.

Put all orphaned subtrees in a FIFO queue; repeatedly dequeue 2, meld them, enqueue the result; stop at 1 tree. Same O(log n) amortized bound as two-pass, but two-pass shows better observed performance in practice — which is why it's the one we animated in full.

A double-ended priority queue (DEPQ) supports: isEmpty(), size(), getMin(), getMax(), put(x), removeMin(), removeMax(). A regular priority queue only ever exposes one end; a DEPQ exposes both, simultaneously, at all times.

Quicksort partitions into Left (≤ pivot), Middle (the pivot), Right (≥ pivot). When the data is too big for memory, an external quicksort makes the Middle group as large as possible using a DEPQ: fill the DEPQ from disk; for every further element, if it's ≤ the DEPQ's current min, ship it straight to Left; if it's ≥ the current max, ship it to Right; otherwise it belongs in the middle — remove either the current min or max to make room, and let the DEPQ hold onto the new element instead. This needs both ends live, continuously — exactly the DEPQ contract.

An interval heap is a complete binary tree in which every node (except possibly the last) holds two elements, a ≤ b — representing the closed interval [a,b]. The rule: every child's interval is contained in its parent's interval. If the last node holds a single element c, then a ≤ c ≤ b for its parent's interval [a,b].

• All the left endpoints, read together, form a valid min-heap.
• All the right endpoints, read together, form a valid max-heap.
• The root's left endpoint is always the overall minimum; the root's right endpoint is always the overall maximum. getMin/getMax are O(1) — just read the root.
• Stored compactly in an array exactly like an ordinary heap, just with two slots per position. Height is Θ(log n) for n elements.

Same shape rule as a binary heap: if the element count is currently odd, a half-full node already exists — the new value fills its free second slot. If the count is even, every node is full, so a brand-new node is created at the next position in the complete tree (left to right, level by level).

Each pair of values (10&90, then 20&70, then 30&80, then 25&50) was inserted back to back, right after its node was created — and each pair already sits inside its parent's interval the moment it arrives. That is a deliberately convenient order. L20·12 reuses this exact heap and inserts 15, 100, and 65 into it — values that do not fit so conveniently, forcing the bubbling you have not seen yet.

• Every element stored exactly once — no correspondence pointers, no duplicated storage, unlike the dual-structure method.
• O(1) getMin and getMax — both just read the root.
• O(log n) put/removeMin/removeMax — a single tree, a single array, ordinary heap-style bookkeeping.
• Widely regarded as the simplest and most efficient of the heap-based DEPQ adaptations — simpler than min-max heaps, twin heaps, deaps, or diamond deques.

• Every node carries two elements, and every insert/remove must maintain the a ≤ b invariant and the containment property simultaneously — more bookkeeping per step than a plain single-value heap node.
• Odd-count edge cases (a single-element last node) need special-casing throughout insert and remove.
• Removing an arbitrary interior element (not just min or max) is possible in O(log n) but is a genuinely fiddlier procedure than an ordinary heap's remove(theNode).

External quicksort's middle group, kept maximal via a live DEPQ — exactly the interval heap's textbook application.

A system tracking both "worst current latency" and "best current latency" across live requests needs both ends of a priority order simultaneously, updated in real time.

Interval heaps also answer "which points lie outside [a,b]?" (the complementary range search problem) in O(k) time for k reported points — a nice bonus of the same structure.