algorithm  non  tail recursion scheme
What is tail recursion? (16)
Whilst starting to learn lisp, I've come across the term tailrecursive. What does it mean exactly?
A tail recursion is a recursive function where the function calls itself at the end ("tail") of the function in which no computation is done after the return of recursive call. Many compilers optimize to change a recursive call to a tail recursive or an iterative call.
Consider the problem of computing factorial of a number.
A straightforward approach would be:
factorial(n):
if n==0 then 1
else n*factorial(n1)
Suppose you call factorial(4). The recursion tree would be:
factorial(4)
/ \
4 factorial(3)
/ \
3 factorial(2)
/ \
2 factorial(1)
/ \
1 factorial(0)
\
1
The maximum recursion depth in the above case is O(n).
However, consider the following example:
factAux(m,n):
if n==0 then m;
else factAux(m*n,n1);
factTail(n):
return factAux(1,n);
Recursion tree for factTail(4) would be:
factTail(4)

factAux(1,4)

factAux(4,3)

factAux(12,2)

factAux(24,1)

factAux(24,0)

24
Here also, maximum recursion depth is O(n) but none of the calls adds any extra variable to the stack. Hence the compiler can do away with a stack.
An important point is that tail recursion is essentially equivalent to looping. It's not just a matter of compiler optimization, but a fundamental fact about expressiveness. This goes both ways: you can take any loop of the form
while(E) { S }; return Q
where E
and Q
are expressions and S
is a sequence of statements, and turn it into a tail recursive function
f() = if E then { S; return f() } else { return Q }
Of course, E
, S
, and Q
have to be defined to compute some interesting value over some variables. For example, the looping function
sum(n) {
int i = 1, k = 0;
while( i <= n ) {
k += i;
++i;
}
return k;
}
is equivalent to the tailrecursive function(s)
sum_aux(n,i,k) {
if( i <= n ) {
return sum_aux(n,i+1,k+i);
} else {
return k;
}
}
sum(n) {
return sum_aux(n,1,0);
}
(This "wrapping" of the tailrecursive function with a function with fewer parameters is a common functional idiom.)
Here is a Common Lisp example that does factorials using tailrecursion. Due to the stackless nature, one could perform insanely large factorial computations ...
(defun ! (n &optional (product 1))
(if (zerop n) product
(! (1 n) (* product n))))
And then for fun you could try (format nil "~R" (! 25))
Here is a quick code snippet comparing two functions. The first is traditional recursion for finding the factorial of a given number. The second uses tail recursion.
Very simple and intuitive to understand.
Easy way to tell if a recursive function is tail recursive, is if it returns a concrete value in the base case. Meaning that it doesn't return 1 or true or anything like that. It will more then likely return some variant of one of the method paramters.
Another way is to tell is if the recursive call is free of any addition, arithmetic, modification, etc... Meaning its nothing but a pure recursive call.
public static int factorial(int mynumber) {
if (mynumber == 1) {
return 1;
} else {
return mynumber * factorial(mynumber);
}
}
public static int tail_factorial(int mynumber, int sofar) {
if (mynumber == 1) {
return sofar;
} else {
return tail_factorial(mynumber, sofar * mynumber);
}
}
In traditional recursion, the typical model is that you perform your recursive calls first, and then you take the return value of the recursive call and calculate the result. In this manner, you don't get the result of your calculation until you have returned from every recursive call.
In tail recursion, you perform your calculations first, and then you execute the recursive call, passing the results of your current step to the next recursive step. This results in the last statement being in the form of (return (recursivefunction params))
. Basically, the return value of any given recursive step is the same as the return value of the next recursive call.
The consequence of this is that once you are ready to perform your next recursive step, you don't need the current stack frame any more. This allows for some optimization. In fact, with an appropriately written compiler, you should never have a snicker with a tail recursive call. Simply reuse the current stack frame for the next recursive step. I'm pretty sure Lisp does this.
In Java, here's a possible tail recursive implementation of the Fibonacci function:
public int tailRecursive(final int n) {
if (n <= 2)
return 1;
return tailRecursiveAux(n, 1, 1);
}
private int tailRecursiveAux(int n, int iter, int acc) {
if (iter == n)
return acc;
return tailRecursiveAux(n, ++iter, acc + iter);
}
Contrast this with the standard recursive implementation:
public int recursive(final int n) {
if (n <= 2)
return 1;
return recursive(n  1) + recursive(n  2);
}
Instead of explaining it with words, here's an example. This is a Scheme version of the factorial function:
(define (factorial x)
(if (= x 0) 1
(* x (factorial ( x 1)))))
Here is a version of factorial that is tailrecursive:
(define factorial
(letrec ((fact (lambda (x accum)
(if (= x 0) accum
(fact ( x 1) (* accum x))))))
(lambda (x)
(fact x 1))))
You will notice in the first version that the recursive call to fact is fed into the multiplication expression, and therefore the state has to be saved on the stack when making the recursive call. In the tailrecursive version there is no other Sexpression waiting for the value of the recursive call, and since there is no further work to do, the state doesn't have to be saved on the stack. As a rule, Scheme tailrecursive functions use constant stack space.
It means that rather than needing to push the instruction pointer on the stack, you can simply jump to the top of a recursive function and continue execution. This allows for functions to recurse indefinitely without overflowing the stack.
I wrote a blog post on the subject, which has graphical examples of what the stack frames look like.
Tail recursion is the life you are living right now. You constantly recycle the same stack frame, over and over, because there's no reason or means to return to a "previous" frame. The past is over and done with so it can be discarded. You get one frame, forever moving into the future, until your process inevitably dies.
_{The analogy breaks down when you consider some processes might utilize additional frames but are still considered tailrecursive if the stack does not grow infinitely.}
Tail recursion refers to the recursive call being last in the last logic instruction in the recursive algorithm.
Typically in recursion you have a basecase which is what stops the recursive calls and begins popping the call stack. To use a classic example, though more Cish than Lisp, the factorial function illustrates tail recursion. The recursive call occurs after checking the basecase condition.
factorial(x, fac) {
if (x == 1)
return fac;
else
return factorial(x1, x*fac);
}
Note, the initial call to factorial must be factorial(n, 1) where n is the number for which the factorial is to be calculated.
The jargon file has this to say about the definition of tail recursion:
tail recursion /n./
If you aren't sick of it already, see tail recursion.
There are two basic kinds of recursions: head recursion and tail recursion.
In head recursion, a function makes its recursive call and then performs some more calculations, maybe using the result of the recursive call, for example.
In a tail recursive function, all calculations happen first and the recursive call is the last thing that happens.
Taken from this super awesome post. Please consider reading it.
This is an excerpt from Structure and Interpretation of Computer Programs about tail recursion.
In contrasting iteration and recursion, we must be careful not to confuse the notion of a recursive process with the notion of a recursive procedure. When we describe a procedure as recursive, we are referring to the syntactic fact that the procedure definition refers (either directly or indirectly) to the procedure itself. But when we describe a process as following a pattern that is, say, linearly recursive, we are speaking about how the process evolves, not about the syntax of how a procedure is written. It may seem disturbing that we refer to a recursive procedure such as factiter as generating an iterative process. However, the process really is iterative: Its state is captured completely by its three state variables, and an interpreter need keep track of only three variables in order to execute the process.
One reason that the distinction between process and procedure may be confusing is that most implementations of common languages (including Ada, Pascal, and C) are designed in such a way that the interpretation of any recursive procedure consumes an amount of memory that grows with the number of procedure calls, even when the process described is, in principle, iterative. As a consequence, these languages can describe iterative processes only by resorting to specialpurpose “looping constructs” such as do, repeat, until, for, and while. The implementation of Scheme does not share this defect. It will execute an iterative process in constant space, even if the iterative process is described by a recursive procedure. An implementation with this property is called tailrecursive. With a tailrecursive implementation, iteration can be expressed using the ordinary procedure call mechanism, so that special iteration constructs are useful only as syntactic sugar.
This question has a lot of great answers... but I cannot help but chime in with an alternative take on how to define "tail recursion", or at least "proper tail recursion." Namely: should one look at it as a property of a particular expression in a program? Or should one look at it as a property of an implementation of a programming language?
For more on the latter view, there is a classic paper by Will Clinger, "Proper Tail Recursion and Space Efficiency" (PLDI 1998), that defined "proper tail recursion" as a property of a programming language implementation. The definition is constructed to allow one to ignore implementation details (such as whether the call stack is actually represented via the runtime stack or via a heapallocated linked list of frames).
To accomplish this, it uses asymptotic analysis: not of program execution time as one usually sees, but rather of program space usage. This way, the space usage of a heapallocated linked list vs a runtime call stack ends up being asymptotically equivalent; so one gets to ignore that programming language implementation detail (a detail which certainly matters quite a bit in practice, but can muddy the waters quite a bit when one attempts to determine whether a given implementation is satisfying the requirement to be "property tail recursive")
The paper is worth careful study for a number of reasons:
It gives an inductive definition of the tail expressions and tail calls of a program. (Such a definition, and why such calls are important, seems to be the subject of most of the other answers given here.)
Here are those definitions, just to provide a flavor of the text:
Definition 1 The tail expressions of a program written in Core Scheme are defined inductively as follows.
 The body of a lambda expression is a tail expression
 If
(if E0 E1 E2)
is a tail expression, then bothE1
andE2
are tail expressions.  Nothing else is a tail expression.
Definition 2 A tail call is a tail expression that is a procedure call.
(a tail recursive call, or as the paper says, "selftail call" is a special case of a tail call where the procedure is invoked itself.)
It provides formal definitions for six different "machines" for evaluating Core Scheme, where each machine has the same observable behavior except for the asymptotic space complexity class that each is in.
For example, after giving definitions for machines with respectively, 1. stackbased memory management, 2. garbage collection but no tail calls, 3. garbage collection and tail calls, the paper continues onward with even more advanced storage management strategies, such as 4. "evlis tail recursion", where the environment does not need to be preserved across the evaluation of the last subexpression argument in a tail call, 5. reducing the environment of a closure to just the free variables of that closure, and 6. socalled "safeforspace" semantics as defined by Appel and Shao.
In order to prove that the machines actually belong to six distinct space complexity classes, the paper, for each pair of machines under comparison, provides concrete examples of programs that will expose asymptotic space blowup on one machine but not the other.
(Reading over my answer now, I'm not sure if I'm managed to actually capture the crucial points of the Clinger paper. But, alas, I cannot devote more time to developing this answer right now.)
Using regular recursion, each recursive call pushes another entry onto the call stack. When the recursion is completed, the app then has to pop each entry off all the way back down.
With tail recursion, depending on language the compiler may be able to collapse the stack down to one entry, so you save stack space...A large recursive query can actually cause a .
Basically Tail recursions are able to be optimized into iteration.
here is a Perl 5 version of the tailrecsum
function mentioned earlier.
sub tail_rec_sum($;$){
my( $x,$running_total ) = (@_,0);
return $running_total unless $x;
@_ = ($x1,$running_total+$x);
goto &tail_rec_sum; # throw away current stack frame
}