To briefly recap, the ability to write recursive iterators is, quite frankly, awesome. But as with any powerful feature you need to be aware of the performance ramifications associated with writing code one way or another. I post a few examples of rewriting recursive iterators as iterative iterators, including binary tree inorder, preorder, and postorder traversals, as well as a solution to the Towers of Hanoi (which, as I also mentioned, is basically an inorder traversal).

Here is another example, the classic permutations problem folks sometimes see in their intro to computer science classes (I've even heard of it being asked in Microsoft interviews). The idea is, given an array, enumerate all of the permutations of that array. A generic recursive iterator solution could be written as follows:

Basically, I start at the beginning of the array (where "beginning" is defined as the lower bound passed to the method, not necessarily 0) and walk along the array, swapping the element at the beginning of the array with the current element. After a swap, I recursively enumerate all of the permutations of the rest of the array, starting at beginning+1. And when I've completed that, I swap back the beginning element with the current element and continue walking along the array. You really have to admire the elegance of recursion.

To turn this into an iterative iterator, one needs to examine exactly where work is being performed in relation to when recursive calls are being made and when values are being returned. In this case, the termination condition is when the beginning of the array is the end of the array, and that's when we stop recurring and yield a value. In all beginning positions, we swap the elements in two positions, recur, and swap them back. Thus, in an iterative version, I need an explicit stack that keeps track of what swaps I've made and when I made them... this requires some information:1. What's the current lower bound? In the recursive version, we're passing that information to the recursive call.2. What's the current element, i.e. what's the value of i as we walk from lower bound to upper bound? In the recursive version, that's maintained as part of the stack frame for each recursive call.3. What's the current upper bound? In the recursive version, we're passing that information to the recursive call. Note, however, that this value never changes; that'll come in handy when writing an iterative version.4. Am I coming or going? In other words, I push some information onto the stack about a swap that's been performed... how do I know when and how to undo that swap? This is implicit in the recursive version.

These questions lead to the following state structure to maintain information about each "recursive call" (since the upper bound is constant, I don't need to include it):

Every time I would make a recursive call in the recursive version, in the iterative version I need to push one of these state structures onto my stack to indicate what operation I need to perform the next time through my loop. In addition, I need another instance of this struct pushed onto the stack to indicate that the operation needs to be undone, and equally important, when. Since a stack is a LIFO data structure, whatever gets pushed onto the stack last will be the first thing out. So, since I need to perform my swap before I undo it, I need to first push the undo information onto the stack, and then push the regular swap information onto the stack. With that in hand, we've basically solved the problem. My solution (which could probably be cleaned up a bit), looks like this:

Now the question becomes a question of worth... does this version perform better than its recursive counterpart? The answer is a definitive maybe. For large arrays, it runs faster. On my machine, iterating over all of the permutations with the recursive version on an array of 12 numbers took over four minutes to finish. The iterative version in the same scenario took under two minutes. An array of 13 numbers with the iterative version finished in approximately 15 minutes, and I didn't have the patience to wait for the recursive version to finish. But for smaller arrays, the difference was fairly negligable, and up until an array of length 10, both versions finished computing all of the permutations in under a second. There are other memory related issues to consider, too. For example, in the recursive version the call stack grows and shrinks, but in the iterative version, the Stack<State> never shrinks. Is that a problem? Probably not. But measuring is the only way to know for sure.

As always, it's good to have a choice, but whether the extra effort is worth it (and whether it will in fact make a positive difference) really depends on the situation. So, profile the code, find your hotspots, and keep this kind of transformation in your bag of tricks in case you need to use it one day.

Sometimes, there’s an iterative algorithm that doesn’t require a stack. Iterating over permutations is an example:

public static IEnumerable<T[]> Permute<T>(T[] arr)

{

Array.Sort(arr);

while (true)

{

yield return arr;

for (int i=arr.Length-2; ; i–)

if (arr[i] < arr[i+1])

{

Array.Reverse(arr, i+1, arr.Length-i-1);

for (int j=i+1; ; j++)

if (arr[i] < arr[j])

{ T t = arr[i]; arr[i] = arr[j]; arr[j] = t; break; }

break;

}

else if (i == 0)

return;

}

}

This algorithm has the advantages of returning the permutations in lexicographic order, and it works even if the array has duplicate entries (each unique permutation is only returned once). It does require that T define a sorting order. (Meaning that it won’t compile as written — T needs to be restricted to IComparable, and it should use CompareTo instead of the < and > operators. Apologies, I don’t have access to a C# 2.0 compiler — this code is adapted from an algorithm to permute ints.)

Of course, there are a plethora of ways to implement a permutation enumeration, some that use recursion and some that don’t, some that maintain lexicographical ordering, some that maintain other orderings, etc. The code you show above doesn’t compile (and fixing the compiler errors appropriately results in IndexOutOfRange exceptions being thrown at runtime), but I think you intended something like the following which does work correctly:

Note that I’ve restricted the generic T parameter to be an IComparable so that I can use the CompareTo method on each element of the array (operators won’t work).

In the previous recursive->iterative example I was just demonstrating one way to do it, and more specifically showing that there’s a pattern you can follow to go from recursive to iterative. That doesn’t mean it’s always something you want to do, as I’ve mentioned.