How does your favorite language handle deep recursion? [closed]

Answer 1

Running ruby 1.9.2dev (2010-07-11 revision 28618) [x86_64-darwin10.0.0] on an older white macbook:

def f
  @i += 1
  f
end

@i = 0

begin
  f
rescue SystemStackError
  puts @i
end

outputs 9353 for me, meaning Ruby craps out with fewer than 10,000 calls on the stack.

With cross-recursion, such as:

def f
  @i += 1
  g
end

def g
  f
end

it craps out in half the time, at 4677 (~= 9353 / 2).

I can squeeze out a few more iterations by wrapping the recursive call in a proc:

def f
  @i += 1
  yield
end

@i = 0
@block = lambda { f(&@block) }

begin
  f(&@block)
rescue SystemStackError
  puts @i
end

which gets up to 4850 before erroring out.

Answer 2

I'm quite a fan of functional programming, and since most of those langauges implement tail call optimization, you can recurse as much as you like :-P

However, practically, I have to use a lot of Java and use Python a lot too. No idea what limit Java has, but for Python I had actually planned (but have not yet done it) to implement a decorator which would tail call optimize the decorated function. I was planning this not to optimize recursion, but mainly as an exercise in dynamically patching Python bytecode and learning more about Pythons internals. Heres some itneresting links: http://lambda-the-ultimate.org/node/1331 and http://www.rowehl.com/blog/?p=626

Answer 3

In some non pathological cases (like your), (latest) Lua will use tail call recursion, ie. it will just jump without pushing data in stack. So the number of recursion loops can be almost unlimited.

Tested with:

function f(i, l)
    if i < l then
        return f(i+1, l)
    end
    return i
end

local val1  = arg[1] or 1
local val2  = arg[2] or 100000000
print(f(val1 + 0, val2 + 0))

Also with:

function g(i, l)
    if i >= l then
        return i
    end
    return g(i+1, l)
end

and even tried cross-recursion (f calling g and g calling f...).

On Windows, Lua 5.1 uses around 1.1MB (constant) to run this, finishes in a few seconds.

Answer 4

There is a way to improve upon the Perl code, to make it use a constant size stack. You do this by using a special form of goto.

sub f{
  if( $_[0] < $_[1] ){

    # return f( $_[0]+1, $_[1] );

    @_ = ( $_[0]+1, $_[1] );
    goto &f;

  } else {
    return $_[0]
  }
}

When first called it will allocate space on the stack. Then it will change its arguments, and restart the subroutine, without adding anything more to the stack. It will therefore pretend that it never called its self, changing it into an iterative process.

---

You could also use the Sub::Call::Recur module. Which makes the code easier to understand, and shorter.

use Sub::Call::Recur;
sub f{
  recur( $_[0]+1, $_[1] ) if $_[0] < $_[1];
  return $_[0];
}

Answer 5

Visual Dataflex will stack overflow.

Answer 6

"The Python folks are quick to point out that you can always convert recursive functions to iterative ones and that they're always faster"

This is true, but if it's really as easy as all that, why doesn't Python do it for me, so that my code can look as simple as possible? (I say this not to slam Python implementers, but because the answer explains the problem).

Recursion optimisations have been present in functional languages since, like, the 14th century or something. Haskell, CAML, Lisp implementations all typically convert at least tail recursive functions to iterations: you basically do this by spotting that it's possible, i.e. that the function can be rearranged such that no local variables other than the return value are used after the recursive call. One trick to make it possible if there's some work done to the recursed return value before return, is to introduce an additional "accumulator" parameter. In simple terms this means the work can effectively be done on the way "down" instead of on the way "up": search around for 'how to make a function tail-recursive' for details.

The actual details of turning a tail recursive function into a loop is basically to jigger with your call convention such you can "perform the call" simply by setting up the parameters and jumping back to the start of the function, without bothering to save all that stuff in scope that you know you won't ever use. In assembler terms, you don't have to preserve caller-saves registers if data-flow analysis tells you they're unused beyond the call, and the same goes for anything on the stack: you don't have to move the stack pointer on a call if you don't mind "your" bit of stack being scribbled over by the next recursion/iteration.

Contrary to how you paraphrased the Python folks, converting a general recursive function to an iteration is not trivial: for example if it's multiply-recursive then in a simple approach you'd still need a stack.

Memoization is a useful technique, though, for arbitrarily recursive functions, that you might like to look up if you're interested in the possible approaches. What it means is that each time a function is evaluated, you stick the result in a cache. To use this to optimize recursion, basically, if your recursive function counts "down", and you memoize it, then you can evaluate it iteratively by adding a loop that counts "up" calculating each value of the function in turn until you reach the target. This uses very little stack space provided that the memo cache is big enough to hold all the values you'll need: for instance if f(n) depends on f(n-1), f(n-2) and f(n-3) you only need space for 3 values in the cache: as you go up you can kick the ladder away. If f(n) depends on f(n-1) and f(n/2), you need lots of space in the cache, but still less than you'd use for stack in an unoptimised recursion.