Thinking Recursively

We begin with a classic puzzle, the Towers of Hanoi (Figure 9-1)

As an example, the sequence of moves necessary to solve the three-disk version of the puzzle is shown in Figure 9-2.

Figure 9-2. There are seven moves in the solution to the three-disk Towers of Hanoi puzzle.

We want to write a program to solve the puzzle. Specifically, it should print out the sequence of moves needed to get all of the disks onto the destination peg. To move three disks from peg 1 to peg 3 (using peg 2 as a spare), our program should print:

1 => 3 1 => 2 3 => 2 1 => 3 2 => 1 2 => 3 1 => 3

Solving the one-disk puzzle is trivial: just move the disk directly from the source peg to the destination peg. We write a simple method (Figure 9-3), which we invoke as hanoi1(1, 3).

Figure 9-3. A method to solve the one-disk Towers of Hanoi puzzle.

To solve the puzzle for two disks, we have to move the small disk to the spare peg to get it out of the way. We can then move the large disk to the destination, and then finally move the small disk back on top of it (Figure 9-4). We need to specify the spare disk as a third argument, so this method is invoked as hanoi2(1, 3, 2).

Figure 9-4. The method for the two-disk puzzle requires an extra argument to identify the spare peg.

The method for the three-disk puzzle (Figure 9-5) is somewhat longer.

The spacing in Figure 9-5 is there to suggest a key insight. The solution can be broken down into three parts. In lines 46, we move two disks from the source to the spare. In line 8, we move the largest disk from the source to the destination. In lines 1012, we move two disks from the spare to the destination.

Figure 9-5. The method hanoi3() is longer, but a pattern begins to emerge.

In lines 46, we are moving the two smallest disks. The location of the larger disk is irrelevant to this task. It is as if we were simply moving the two disks by themselves, and we already know how to do this. We can do this by invoking hanoi2(). The same is true of lines 1012. We can therefore write a shorter version of hanoi3() (Figure 9-6).

Figure 9-6. An improved version of hanoi3() invokes hanoi2(). Line 3 moves two disks from source to spare. Line 5 moves two disks from spare to dest.

Similarly, we can rewrite hanoi2() using hanoi1() (Figure 9-7).

Figure 9-7. The method hanoi2() can be rewritten using hanoi1().

We now have a pattern that will allow us to write a method to solve the puzzle for any number of disks, provided that we've written all of the previous methods. For example, once we've written hanoi1() tHRough hanoi16(), we can write hanoi17() (Figure 9-8).

Figure 9-8. The pattern can be extended to any number of disks.

This is fine, but we still have to do the tedious work of writing all these methods. It would be much better if we could write a single method which would work for any number of disks. This method has to accept the number of disks as an argument. A first attempt is shown in Figure 9-9. A method which invokes itself like this is called recursive.

Figure 9-9. First attempt at a method to solve the puzzle for any number of disks.

Unfortunately, this method is slightly broken. If we ask for

hanoi(1, 1, 3, 2);

the program crashes, giving an error message like:

java.lang.StackOverflowError

We'll explain this message in more detail in Section 9.5. For now, let's step through the execution and see if we can figure out what happened.

The method begins by invoking

hanoi(0, 1, 2, 3);

which invokes

hanoi(-1, 1, 3, 2);

which invokes

hanoi(-2, 1, 2, 3);

and so on, until the computer runs out of memory. To prevent this, we have to provide a base casethat is, some situation where the problem is so simple that the method does not have to recursively invoke itself. For the Towers of Hanoi puzzle, the base case is the situation where there is only one disk. Once we check for the base case (Figure 9-10), our method works correctly.

Figure 9-10. A correct recursive program must check for the base case.

In general, to solve a problem recursively, we must deal with two cases:

1. The base case, where we can solve the problem directly, and
2. The recursive case, where we solve the problem in terms of easier subproblems.

When we say that subproblems must be "easier," we mean that they must be closer to the base case. In the Towers of Hanoi, we solve the problem of moving n disks in terms of the easier problem of moving n 1 disks.

For a second example of recursion, consider the task of printing a LinkedList backward. An iterative approach (that is, one using loops instead of recursion) would be to find the last item, then the second-to-last item, and so on (Figure 9-11).

Figure 9-11. An iterative toStringReversed() method for our LinkedList class.

This method works, but it is not very efficient. Each invocation of get() requires us to walk down the list from the beginning to find the item at position i, which takes time linear in i. The total time for this version of toStringReversed() is:

(We are pretending here that String concatenation takes constant time, which is not exactly true. More on this in Chapter 13.)

A better recursive solution is to divide the problem into two cases:

1. If there are no nodes, return the empty String.
2. Otherwise, generate a String for the rest of the list (the part after the first item). Add the first item to the end of this String and return it.

We would like to add parentheses at the beginning and end of the list. We could deal with the left parenthesis in the base case, but there's no good time to add the right parenthesis. To avoid this complication, we move the recursive part of the problem into a separate helper method (Figure 9-12).

Figure 9-12. An alternate version of toStringReversed() invokes a recursive helper method.

Notice that toStringReversedHelper() does not deal with the entire list, but merely the chain of nodes starting at node.

To show that a recursive algorithm works correctly, we must demonstrate that:

1. The base case works correctly, and
2. If the recursive method works for a problem of size n 1, then it works for a problem of size n.

In this case, toStringReversedHelper() certainly works correctly for the base case, where node is null. It returns the empty String, so toStringReversed() returns "( )".

Now suppose node is not null, but instead is a reference to the first of a chain of n nodes (Figure 9-13).

Figure 9-13. A chain of n nodes consists of a first node followed by n 1 more nodes.

If we assume that the recursive invocation

toStringReversedHelper(node.getNext())

correctly returns the String "D C B ", then clearly the expression

toStringReversedHelper(node.getNext()) + node.getItem() + " "

evaluates to "D C B A ", which is what we want. In general, if the method works for a chain of n 1 nodes, it works for a chain of n nodes.

Since we know that the method works properly for an empty chain (null), we can now conclude that it works for a chain of one node. From this, we can conclude that it works for a chain of two nodes. Indeed, we can conclude that it works for any number of nodes.

Let's write toStringReversed() for our ArrayList class as a third and final example of recursion. It would be easyand indeed, more naturalto do this one using a for loop, but it can also be done using recursion. In fact, any recursive procedure can be written iteratively, and vice versa.

Again we need a helper method, and the design of the algorithm is similar:

1. If there are no elements being considered, return the empty String.
2. Otherwise, generate a String for all of the elements after the current one. Add the current element to the end of this String and return it.

The code is shown in Figure 9-14, emphasizing the parts which are different from the LinkedList versions.

Figure 9-14. The method toStringReversed() and the recursive method toStringReversedHelper() for our ArrayList class.

Exercises