Towers of Hanoi with K pegs
Data Structures & Algorithms practice on Codemia
Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.
Introduction
The three-peg Towers of Hanoi is a standard recursion exercise, but the puzzle becomes much more interesting when you allow k pegs instead of only three. With extra pegs, the simple 2 ** n - 1 formula no longer applies, so the problem turns into a search for the best way to split the tower.
The Three-Peg Baseline
With three pegs, the strategy is fixed. To move n disks from a source peg to a target peg, you move n - 1 disks out of the way, move the largest disk once, and then move the n - 1 disks back on top of it.
That gives the recurrence:
- '
T(1, 3) = 1' - '
T(n, 3) = 2 * T(n - 1, 3) + 1'
The closed form is 2 ** n - 1.
This works because there is only one spare peg. Once more pegs are available, there are many possible ways to stage the smaller disks.
The Frame-Stewart Idea
For k pegs, a practical strategy is:
- move the top
mdisks to a spare peg using allkpegs - move the remaining
n - mdisks to the target using onlyk - 1pegs - move the stored
mdisks onto the target using allkpegs
That gives the Frame-Stewart recurrence:
- '
T(n, k) = min over m of 2 * T(m, k) + T(n - m, k - 1)'
The best split value m depends on the number of disks and the number of pegs, so you usually compute it with dynamic programming.
Computing the Minimum Move Count
Memoization makes the recurrence practical because the same subproblems appear over and over.
For the common four-peg variant, this gives the minimal move counts for small and medium inputs very quickly. A naive recursive version is much slower because it recomputes the same n, k states repeatedly.
Reconstructing a Strategy
If you need the move sequence rather than only the count, store the best split for each state and reuse it during a second recursive pass.
The move generator is longer because it must track which pegs are acting as source, target, and temporary storage, but it follows the same three-phase pattern.
Common Pitfalls
The biggest mistake is applying the three-peg formula to the k-peg puzzle. Once more than three pegs exist, 2 ** n - 1 is no longer the general answer.
Another issue is skipping memoization. The recurrence has heavy overlap, so plain recursion becomes expensive surprisingly fast.
Some solutions also hard-code a split rule that works for a few sample cases but is not actually optimal. The whole point of the Frame-Stewart approach is to test candidate split values and keep the cheapest one.
Finally, a correct counting function does not automatically mean the move list is valid. When generating the sequence, you must still respect the rule that a larger disk can never be placed on a smaller disk.
Summary
- The classic three-peg puzzle has the closed form
2 ** n - 1. - The multi-peg version is usually modeled with the Frame-Stewart recurrence.
- Memoization is essential because the same subproblems repeat.
- Extra pegs help only if you choose a good split point for the top block.
- Computing the move count and emitting a valid move sequence are separate tasks.
Related reading
- Trained Machine Learning model is too big
- Training a simple model in Tensorflow GPU slower than CPU
- Training broke with ResourceExausted error
- training by batches leads to more over-fitting
- Training of keras model get's slower after each repetition
- Traveling salesman example with known global optimum
- Travelling Salesman with multiple salesmen?
- Travelling Salesman with multiple salesmen with a limit on number of cities per salesman?

DSA Fundamentals
Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Data Structures & Algorithms practice on Codemia
Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.