Cheapest merging (Huffman-style)
In one line
When combining two items costs their total size and you must combine everything, always merge the two smallest first, using a min-heap.
What it is
Many problems repeatedly merge two items into one where the cost of a merge is the sum of their sizes: connecting ropes or sticks, merging sorted files into one, building a Huffman code. The total cost depends heavily on the order.
Every original item's size is paid once for each merge it takes part in, so big items should be merged as few times as possible, meaning as late as possible. The greedy rule is: always merge the two currently smallest items. A min-heap makes each step O(log n).
Huffman coding is the famous application: symbols are items, their frequencies are sizes, and the merge tree becomes a prefix code. Frequent symbols end up near the root with short codes, rare ones deep with long codes, and the total encoded length is minimised among all prefix codes.
Why interviewers ask
Interviewers ask 'minimum cost to connect sticks' or Huffman coding to test heap usage and greedy reasoning together. They also check that you notice when the rule does not apply: if you may only merge adjacent piles (merge stones), the order is constrained and you need interval DP instead.
How it works
- 1Put all sizes in a min-heap: O(n) with heapify.
- 2While more than one item remains, pop the two smallest a and b, add a + b to the total cost, and push a + b back.
- 3After n - 1 merges one item is left; the accumulated total is the answer.
- 4Why it works: the total cost equals the sum over items of size x depth in the merge tree. In some optimal tree the two smallest items can be swapped into the deepest pair of siblings without increasing the cost (an exchange argument), so merging them first is safe, and the rest is the same problem with one fewer item.
- 5For Huffman coding, also record each merge as a parent node; reading left = 0 and right = 1 from the root gives each symbol's code.
Worked example · Sticks [4, 3, 2, 6] and a small Huffman code
- Heap {2, 3, 4, 6}. Merge 2 + 3 = 5, cost 5. Heap {4, 5, 6}.
- Merge 4 + 5 = 9, cost 5 + 9 = 14. Heap {6, 9}.
- Merge 6 + 9 = 15, cost 14 + 15 = 29. One stick left: answer 29.
- Merging in the given order instead (4 + 3 = 7, 7 + 2 = 9, 9 + 6 = 15) costs 7 + 9 + 15 = 31, so order matters.
- Huffman with frequencies a:5, b:9, c:12, d:13, e:16, f:45 (100 characters). Merges: 5+9=14, 12+13=25, 14+16=30, 25+30=55, 45+55=100.
- Total cost 14 + 25 + 30 + 55 + 100 = 224 bits. f gets a 1-bit code, c, d and e get 3 bits, a and b get 4 bits, versus 300 bits with a fixed 3-bit code.
Picture it
Think of carrying shopping bags up stairs where each time you combine two bags you have to lift the combined weight. You would combine the light bags first and add the heavy one at the very end, so the heavy one is lifted as few times as possible.
Reference code
import heapq
def min_cost_connect(sticks):
"""Join all sticks; joining lengths a and b costs a + b."""
heap = list(sticks)
heapq.heapify(heap)
total = 0
while len(heap) > 1:
a = heapq.heappop(heap) # two smallest
b = heapq.heappop(heap)
total += a + b
heapq.heappush(heap, a + b)
return total
# min_cost_connect([4, 3, 2, 6]) -> 29
# Huffman: with frequencies [5, 9, 12, 13, 16, 45] the same loop
# returns 224, the total number of bits in the encoded text.
heapify is O(n), then n - 1 rounds of two pops and one push, each O(log n), for O(n log n) total time and O(n) space.
Key patterns
Connect ropes / sticks
When: Merge any two items, cost = their sum, minimise total
How: Min-heap, pop two smallest, push the sum, add to the total.
Huffman coding
When: Build an optimal prefix code from symbol frequencies
How: Same merging, but keep tree nodes; code length = depth of the leaf.
k-way merge cost
When: Merges combine k items at a time
How: Pad with zeros until (n - 1) is divisible by (k - 1), then always merge the k smallest.
Adjacent-only merging (not greedy)
When: Only neighbouring piles can be merged (merge stones)
How: Use interval DP over [i, j] with prefix sums; greedy two-smallest is wrong because the smallest may not be adjacent.
Real-world use
File compression
DEFLATE, used by zip, gzip and PNG, builds Huffman codes for literals and match lengths, and baseline JPEG uses Huffman tables for its coefficients. The two-smallest merge produces the code lengths.
Merging sorted runs
External sorting and database or log-structured storage engines merge sorted files; when merges are done two at a time, merging the smallest files first (the optimal merge pattern) minimises total bytes rewritten.
Network and cable joining
Joining many segments where each join's cost is proportional to the combined length or load is the 'connect ropes' problem in practice.
Building balanced decision trees
Huffman-style merging is used to build trees where frequent cases are near the root, such as hierarchical softmax in word2vec, which builds a Huffman tree over words by frequency.
In a project
You maintain a logging pipeline that writes hundreds of small sorted log segment files per hour, and a nightly job merges them into one sorted file. The job takes too long and rewrites too much data.
- Model each merge of two files as costing the sum of their sizes, because both are read and the result is written.
- Put file sizes into a min-heap and always merge the two smallest files, pushing the result back.
- Compare the bytes rewritten against the current order (merge in arrival order) on a week of real file sizes.
- If the storage engine can merge k files at once, generalise: pop the k smallest each time and pad with zero-size dummies so the count works out.
Impact: The nightly job rewrites far fewer bytes because large files are touched only once or twice at the end, which shortens the job and reduces disk wear; the improvement is measurable directly as bytes written.
Trade-offs
Use it when
- Any two items may be merged and the cost is the sum of their sizes
- Building an optimal prefix code from frequencies
- Minimising total work when merging sorted runs pairwise
Avoid it when
- Only adjacent items can be merged: use interval DP
- Merge cost is not additive (for example the max of the two, or a fixed cost)
- You need codes that adapt as data streams in; static Huffman needs frequencies up front (use adaptive coding or arithmetic coding)
Cost: O(n log n) time with a binary heap and O(n) space; with already sorted input, a two-queue method runs in O(n).
Common mistakes
- Sorting once and merging left to right without re-inserting the merged item in order.
- Using the greedy for merge stones where only adjacent piles may be merged.
- Counting cost as only the final size instead of the sum of every merge.
- Forgetting the single-item case: no merges, cost 0.
- Claiming Huffman is optimal among all compression schemes; it is optimal among prefix codes with one code per symbol.
Interview questions
Quick revision
- Cost = sum over items of size x number of merges it is in.
- Rule: merge the two smallest, push the sum back.
- Min-heap: O(n log n) time, O(n) space.
- [4,3,2,6] costs 29; Huffman example 5,9,12,13,16,45 costs 224 bits.
- Huffman: frequent symbols get short codes; optimal among prefix codes.
- Adjacent-only merging is interval DP, not greedy.
- k-way: pad with zeros so (n - 1) % (k - 1) == 0.
Check yourself
1. What is the minimum total cost to connect sticks [4, 3, 2, 6]?
2. Which data structure makes the greedy merge efficient?
3. In a Huffman code, which symbols get the shortest codes?
4. Piles can only be merged with their neighbours. Which approach is correct?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.