I am new to C and I'm reading about recursion, but I am totally confused.
The main part where I'm getting confused is how things get unwind when the exit condition is reached. I would like to know how during recursion values got pushed and popped from stack.
Also can anyone please give me a diagramatic view of recursion?
Thanks...
Lets assume a function:
int MyFunc(int counter) {
// check this functions counter value from the stack (most recent push)
// if counter is 0, we've reached the terminating condition, return it
if(counter == 0) {
return counter;
}
else {
// terminating condition not reached, push (counter-1) onto stack and recurse
int valueToPrint = MyFunc(counter - 1);
// print out the value returned by the recursive call
printf("%d", valueToPrint);
// return the value that was supplied to use
// (usually done via a register I think)
return counter;
}
}
int main() {
// Push 9 onto the stack, we don't care about the return value...
MyFunc(9);
}
The output is: 012345678
The first time through MyFunc, count is 9. It fails the terminating check (it is not 0), so the recursive call is invoked, with (counter -1), 8.
This repeats, decrementing the value pushed onto the stack each time until counter == 0. At this point, the terminating clause fires and the function simply returns the value of counter (0), usually in a register.
The next call up the stack, uses the returned value to print (0), then returns the value that was supplied into it when it was called (1). This repeats:
The next call up the stack, uses the returned value to print (1), then returns the value that was supplied into it when it was called (2). etc, till you get to the top of the stack.
So, if MyFunc was invoked with 3, you'd get the equivalent of (ignoring return addresses etc from the stack):
Call MyFunc(3) Stack: [3]
Call MyFunc(2) Stack: [2,3]
Call MyFunc(1) Stack: [1,2,3]
Call MyFunc(0) Stack: [0,1,2,3]
Termination fires (top of stack == 0), return top of stack(0).
// Flow returns to:
MyFunc(1) Stack: [1,2,3]
Print returned value (0)
return current top of stack (1)
// Flow returns to:
MyFunc(2) Stack: [2,3]
Print returned value (1)
return current top of stack (2)
// Flow returns to:
MyFunc(3) Stack: [3]
Print returned value (2)
return current top of stack (3)
// and you're done...
How things get unwind when the exit condition is reached?
First, few words about recursion: a divide and conquer method used for complex tasks that can be gradually decomposed and reduced to a simple instances of the initial task until a form(base case) that allows direct calculation is reached. It is a notion closely related to mathematical induction.
More specifically, a recursive function calls itself, either directly or indirectly. In direct recursion function, foo(), makes another call to itself. In indirect recursion, function foo() makes a call to function moo(), which in turn calls function foo(), until the base case is reached, and then, the final result is accumulated in the exact reverse order of the initial recursive function call.
Example:
Factorial n, denoted n!, is the product of positive integers from 1 to n. The factorial can be formally defined as: factorial(0)=1, (base case) factorial(n)= n * factorial(n-1), for n > 0. (recursive call)
Recursion shows up in this definition as we define factrorial(n) in terms of factorial(n-1).
Every recursion function should have termination condition to end recursion. In this example, when n=0, recursion stops. The above function expressed in C is:
int fact(int n){
if(n == 0){
return 1;
}
return (n * fact(n-1));
}
This example is an example of direct recursion.
How is this implemented? At the software level, its implementation is not different from implementing other functions(procedures). Once you understand that each procedure call instance is distinct from the others, the fact that a recursive function calls itself does not make any big difference.
Each active procedure maintains an activation record, which is stored on the stack. The activation record consists of the arguments, return address (of the caller), and local variables.
The activation record comes into existence when a procedure is invoked and disappears after the procedure is terminated and the result is returned to the caller. Thus, for each procedure that is not terminated, an activation record that contains the state of that procedure is stored. The number of activation records, and hence the amount of stack space required to run the program, depends on the depth of recursion.
Also can anyone please give me a diagramatic view of recursion?
Next figure shows the activation record for factorial(3):
As you can see from the figure, each call to the factorial creates an activation record until the base case is reached and starting from there we accumulate the result in the form of product.
In C recursion is just like ordinary function calls.
When a function is called, the arguments, return address, and frame pointer (I forgot the order) are pushed on the stack.
In the called function, first the space for local variables is "pushed" on the stack.
if function returns something, put it in a certain register (depends on architecture, AFAIK)
undo step 2.
undo step 1.
So, with recursion steps 1 and 2 are performed a few times, then possibly 3 (maybe only once) and finally 4 and 5 are done (as many times as 1 and 2).
An alternative answer is that in general you don't know. C as a language doesn't have any stack of heap. Your compiler uses a memory location called the stack to store control flow information such as stack frames, return addresses and registers, but there is nothing in C prohibiting the compiler to store that information elsewhere. For practical aspects the previous answers are correct. This is how C compilers operate today.
This question has been widely answered. Allow me please to incorporate an additional answer using a more pedagogical approach.
You can think function recursion as a stack of bubbles with two differentiate stages: pushing stage and bursting stage.
A) PUSHING STAGE (or "Pushing the stack", as OP call it)
0) The starting Bubble #0 is the MAIN function. It is blown up with this information:
Local variables.
The call to the next Bubble #1 (the first call to the recursive
function, MYFUNC).
1) Bubble #1 is blown up on its turn with this information:
Parameters from the previous Bubble #0.
Local variables if necessary.
A returning address.
Terminating check with a returning value (eg: if (counter == 0) {return 1}).
A call to the next Bubble #2.
Remember that this bubble, as the other bubbles, is the recursive function MYFUNC.
2) Bubble #2 is blown up with the same information as Bubble #1, getting from the latter the necessary input (parameters). After this point, you can stack as many bubbles as you want inflating the information accordingly to the listed items in Bubble #1.
i) So you get as many bubbles as you want: Bubble #3, Bubble #4..., Bubble #i. The very last bubble has a NAIL in the terminating check. Be aware!
B) BURSTING STAGE (or "Popping the stack", as OP call it)
This stage happens when you reach the positive terminating check and the last bubble containing the nail is burst.
Let's say this stage happens in Bubble #3. The positive terminating check is reached and Bubble #3 is burst. Then the NAIL from this bubble is liberated. This nail falls on the underneath Bubble #2 and burst it. After this happens the nail follows its fall until it burst Bubble #1. The same happens to Bubble #0. It is important to notice that the nail follows the returning address in the bubble that it's being burst at the moment: the address tells the nail which direction to follow while falling.
At the end of this process, the answer is obtained and delivered to the MAIN function (or Bubble #0, which of course is not burst).
C) GRAPHICALLY (as OP asked)
This is the graphical explanation. It evolves from the bottom, Bubble #0 to top, Bubble #3.
/*Bubble #3 (MYFUNC recursive function): Parameters from Bubble #2,
local variables, returning address, terminating check (NAIL),
call (not used here, as terminating check is positive).*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #2
/*Bubble #2 (MYFUNC recursive function): Parameters from Bubble #1,
local variables, returning address, terminating check (not used),
call to Bubble #3.*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #1
/*Bubble #1 (MYFUNC recursive function): Parameters from Bubble #0,
local variables, returning address, terminating check (not used),
call to Bubble #2.*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #0
/*Bubble #0 (MAIN function): local variables, the first call to Bubble #1.*/
Hope this approach helps someone. Let me know if any clarification is needed.
Consider the given two arrays A and B without repetitions (that
is, no double occurrences of the same element). The task is to check whether
each element of B is also an element of A without regard to the order.
For instance if A = [1, 2, 3, 4] and B = [2, 3, 1] then the answer is YES. If
however B = [1, 2, 5] then the answer is NO because 5 is not in A.
Design a recursive algorithm (no use of loops) for the above problem.
I am trying to solve the above problem, and there is no way I can find to solve it without using the loop. Would anyone know a way to solve this with recursion without using a loop?
I can not use any builtin functions, this is a recursion exercise for algorithms and data structures.
You can convert a loop to recursion by designing a recursive function/method that operates on a part of your original array (technically on a sub-array) (initially the sub-array will be your complete array) and reducing the size of the array (each time you are passing to your recursive method) by 1.
The following method (I've the implementation in Java) simply checks if the given number is present in the array/list. But notice that it also takes startIndex and endIndex which specifically denotes our boundaries of sub-array/sub-list.
In simple words the following method checks whether the given number is present in list or not but the check is done only between startIndex and endIndex both inclusive. Consider that you pass each element of your array B (listB in my case) to this method, and list argument is actually a reference to your array A (listA in my case).
/**
* This method recursively checks whether given
* number is contained in the given list or not.
*
* For this method startIndex and endIndex
* correspond to the indices of listA
*/
private static boolean contains(List<Integer> list, int startIndex, int endIndex, int number) {
if (startIndex == endIndex) {
return list.get(startIndex) == number;
} else if (startIndex < endIndex) {
return list.get(startIndex) == number || contains(list, startIndex + 1, endIndex, number);
}
// should never be the case
return true;
}
Now, once you have the above method, you can now device a recursive method that pics up all the elements of listB one at a time, and "plugs it in" inside the above method. This can be preciously done as follows:
/**
* This method recurse over each element of listB and checks
* whether the current element is contained in listA or not
*
* for this method startIndex and endIndex correspond to the
* indices of listB
*/
private static boolean contains(List<Integer> listA, List<Integer> listB, int startIndex, int endIndex) {
if (startIndex > endIndex) {
return true;
}
boolean c = contains(listA, 0, listA.size() - 1, listB.get(startIndex));
if (!c) {
return false;
}
return contains(listA, listB, startIndex + 1, endIndex);
}
And a call to above method will look like contains(listA, listB, 0, listB.size() - 1)
Bingo!! You are done.
I'd like you to think of recursive functions in a specific manner. Think of them as like what arguments it take, and what it does. So when you have a recursive call inside the recursive method, you don't need to think how that recursive call will work, rather have an abstraction there and believe that the recursive call will give you the result. Now focus on how you can use this returned result to make this recursive method correctly work.
One way is to turn a simple iterative algorithm -- with a nested loop -- into a recursive one.
An iterative solution, which is not optimised to use a map, but has a O(n²) time complexity, would look like this:
function includesValue(A, v):
for i = 0 to length(A) - 1:
if A[i] == v:
return true
return false
function includesArray(A, B):
for j = 0 to length(B) - 1:
if not includesValue(A, B[j]):
return false
return true
If you translate this into a recursive pattern, you could pass the current index as an extra argument:
function recIncludesValueAfter(A, v, i):
if i >= length(A):
return false
if A[i] == v:
return true
return recIncludesValuesAfter(A, v, i + 1)
function recIncludesSubArray(A, B, j):
if j >= length(B):
return true
if not recIncludesValueAfter(A, B[j], 0):
return false
return recIncludesSubArray(A, B, j + 1)
You would call it with the third argument as 0:
recIncludesSubArray(A, B, 0)
Each of the two recursive functions uses this pattern:
The first if block corresponds to the end of the loop in the iterative version
The second if block corresponds to the body of the for loop in the iterative version (including its potential break-out)
The final recursive call corresponds to the launch of a next iteration in the iterative version.
Optimised by using a Map/Set
If you would need an optimised version, using a set (a map where only the key is important, not the value associated with it), then the iterative version would look like this:
function includesArray(A, B):
setA = new Set
for i = 0 to length(A):
setA.add(A[i])
for j = 0 to length(B) - 1:
if setA.has(B[j]):
return false
return true
Again, we can convert this to a recursive version:
function recAddSubArrayToSet(setA, B, j):
if j >= length(B):
return setA
setA.add(B[j])
return recAddSubArrayToSet(setA, B, j + 1)
function recSetIncludesSubArray(setA, B, j):
if j >= length(B):
return true
if not setA.has(B[j]):
return false
return recSetIncludesSubArray(A, B, j + 1)
function recIncludesSubArray(A, B):
setA = new empty Set
recAddSubArrayToSet(setA, B, 0)
return recSetIncludesSubArray(setA, B, 0)
About built-in functions
You wrote that built-in functions are not allowed. This is a constraint that only makes sense when you have a specific target programming language in mind. In pseudo code there is no concept of built-in functions.
Some languages will provide maps/sets/dictionaries in a way where you can only do something useful with them by calling methods on them (built-in), while other languages will allow you to apply operators (like +) on them, and use an in operator to test membership.
But even getting the size of an array may need a function call in some languages. So this constraint really only makes sense in the context of a specific programming language.
Pseudocode for a function that recursively tests whether the array A contains a given element, x might look something like this:
function isMember(x, A):
if A = [] then return false
if x = A[0] then return true
return isMember(x, A[1..-1])
end
This function is built on the premise that to test if x is a member of A, we can test to see if the first element of A, denoted A[0], is the same as x. If so, we can terminate the function and return true. If not, then call the function again, passing it all the elements of array A except the first one that we already tested. I've denoted the remaining elements of A with A[1..-1], i.e. element numbers 1 through to -1, which in some languages is another way to refer to the last element.
Now during the second call to this function, x is being compared to the first element of A[1..-1], which is, of course, the second element of A. This recurses over and over, each time shrinking the size of array A the element at the top of the list is tested and discarded.
Then we eventually reach the final case, where there are no more elements left in A to test, which results in the final recursive call to the function being passed an empty array. In this situation, we can infer that every element in A failed to match with x, and so we can safely return false, stating the x is not a member of A.
Now, in order to determine whether a given array B is contained by array A, each element in B needs to undergo the test described above. If isMember() returns true for every element in B, then B must be contained by A. If any one element causes isMember() to return false, then we can stop further testing because B contains elements that are not in A, so it cannot be a subarray.
Here's some pseudocode that illustrates this recursive process:
function containedBy(B, A):
if B = [] then return true
let x := B[0]
if not isMember(x, A) then return false
return containedBy(B[1..-1], A)
end
It's very similar in many ways to the first function, which isn't surprising. This time, however, array B is reduced in size with each recursion, as its lead element is passed through to the isMember() function, then discarded upon isMember() returning true. As before, the final case after the last recursive call to containedBy() passes through an empty list in place of B. This can only mean that every element of B successfully passed the membership test with A, so we return true to confirm that B is, indeed, contained by A.
Whilst starting to learn lisp, I've come across the term tail-recursive. What does it mean exactly?
Consider a simple function that adds the first N natural numbers. (e.g. sum(5) = 0 + 1 + 2 + 3 + 4 + 5 = 15).
Here is a simple JavaScript implementation that uses recursion:
function recsum(x) {
if (x === 0) {
return 0;
} else {
return x + recsum(x - 1);
}
}
If you called recsum(5), this is what the JavaScript interpreter would evaluate:
recsum(5)
5 + recsum(4)
5 + (4 + recsum(3))
5 + (4 + (3 + recsum(2)))
5 + (4 + (3 + (2 + recsum(1))))
5 + (4 + (3 + (2 + (1 + recsum(0)))))
5 + (4 + (3 + (2 + (1 + 0))))
5 + (4 + (3 + (2 + 1)))
5 + (4 + (3 + 3))
5 + (4 + 6)
5 + 10
15
Note how every recursive call has to complete before the JavaScript interpreter begins to actually do the work of calculating the sum.
Here's a tail-recursive version of the same function:
function tailrecsum(x, running_total = 0) {
if (x === 0) {
return running_total;
} else {
return tailrecsum(x - 1, running_total + x);
}
}
Here's the sequence of events that would occur if you called tailrecsum(5), (which would effectively be tailrecsum(5, 0), because of the default second argument).
tailrecsum(5, 0)
tailrecsum(4, 5)
tailrecsum(3, 9)
tailrecsum(2, 12)
tailrecsum(1, 14)
tailrecsum(0, 15)
15
In the tail-recursive case, with each evaluation of the recursive call, the running_total is updated.
Note: The original answer used examples from Python. These have been changed to JavaScript, since Python interpreters don't support tail call optimization. However, while tail call optimization is part of the ECMAScript 2015 spec, most JavaScript interpreters don't support it.
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 (recursive-function 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 stack overflow snicker with a tail recursive call. Simply reuse the current stack frame for the next recursive step. I'm pretty sure Lisp does this.
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 tail-recursive 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 tail-recursive function with a function with fewer parameters is a common functional idiom.)
This excerpt from the book Programming in Lua shows how to make a proper tail recursion (in Lua, but should apply to Lisp too) and why it's better.
A tail call [tail recursion] is a kind of goto dressed
as a call. A tail call happens when a
function calls another as its last
action, so it has nothing else to do.
For instance, in the following code,
the call to g is a tail call:
function f (x)
return g(x)
end
After f calls g, it has nothing else
to do. In such situations, the program
does not need to return to the calling
function when the called function
ends. Therefore, after the tail call,
the program does not need to keep any
information about the calling function
in the stack. ...
Because a proper tail call uses no
stack space, there is no limit on the
number of "nested" tail calls that a
program can make. For instance, we can
call the following function with any
number as argument; it will never
overflow the stack:
function foo (n)
if n > 0 then return foo(n - 1) end
end
... As I said earlier, a tail call is a
kind of goto. As such, a quite useful
application of proper tail calls in
Lua is for programming state machines.
Such applications can represent each
state by a function; to change state
is to go to (or to call) a specific
function. As an example, let us
consider a simple maze game. The maze
has several rooms, each with up to
four doors: north, south, east, and
west. At each step, the user enters a
movement direction. If there is a door
in that direction, the user goes to
the corresponding room; otherwise, the
program prints a warning. The goal is
to go from an initial room to a final
room.
This game is a typical state machine,
where the current room is the state.
We can implement such maze with one
function for each room. We use tail
calls to move from one room to
another. A small maze with four rooms
could look like this:
function room1 ()
local move = io.read()
if move == "south" then return room3()
elseif move == "east" then return room2()
else print("invalid move")
return room1() -- stay in the same room
end
end
function room2 ()
local move = io.read()
if move == "south" then return room4()
elseif move == "west" then return room1()
else print("invalid move")
return room2()
end
end
function room3 ()
local move = io.read()
if move == "north" then return room1()
elseif move == "east" then return room4()
else print("invalid move")
return room3()
end
end
function room4 ()
print("congratulations!")
end
So you see, when you make a recursive call like:
function x(n)
if n==0 then return 0
n= n-2
return x(n) + 1
end
This is not tail recursive because you still have things to do (add 1) in that function after the recursive call is made. If you input a very high number it will probably cause a stack overflow.
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 stack overflow.
Basically Tail recursions are able to be optimized into iteration.
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.
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 tail-recursive:
(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 tail-recursive version there is no other S-expression 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 tail-recursive functions use constant stack space.
Tail recursion refers to the recursive call being last in the last logic instruction in the recursive algorithm.
Typically in recursion, you have a base-case which is what stops the recursive calls and begins popping the call stack. To use a classic example, though more C-ish than Lisp, the factorial function illustrates tail recursion. The recursive call occurs after checking the base-case condition.
factorial(x, fac=1) {
if (x == 1)
return fac;
else
return factorial(x-1, x*fac);
}
The initial call to factorial would be factorial(n) where fac=1 (default value) and n is the number for which the factorial is to be calculated.
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.
The best way for me to understand tail call recursion is a special case of recursion where the last call(or the tail call) is the function itself.
Comparing the examples provided in Python:
def recsum(x):
if x == 1:
return x
else:
return x + recsum(x - 1)
^RECURSION
def tailrecsum(x, running_total=0):
if x == 0:
return running_total
else:
return tailrecsum(x - 1, running_total + x)
^TAIL RECURSION
As you can see in the general recursive version, the final call in the code block is x + recsum(x - 1). So after calling the recsum method, there is another operation which is x + ...
However, in the tail recursive version, the final call(or the tail call) in the code block is tailrecsum(x - 1, running_total + x) which means the last call is made to the method itself and no operation after that.
This point is important because tail recursion as seen here is not making the memory grow because when the underlying VM sees a function calling itself in a tail position (the last expression to be evaluated in a function), it eliminates the current stack frame, which is known as Tail Call Optimization(TCO).
EDIT
NB. Do bear in mind that the example above is written in Python whose runtime does not support TCO. This is just an example to explain the point. TCO is supported in languages like Scheme, Haskell etc
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.
An easy way to tell if a recursive function is a 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 than likely return some variant of one of the method parameters.
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);
}
}
The recursive function is a function which calls by itself
It allows programmers to write efficient programs using a minimal amount of code.
The downside is that they can cause infinite loops and other unexpected results if not written properly.
I will explain both Simple Recursive function and Tail Recursive function
In order to write a Simple recursive function
The first point to consider is when should you decide on coming out
of the loop which is the if loop
The second is what process to do if we are our own function
From the given example:
public static int fact(int n){
if(n <=1)
return 1;
else
return n * fact(n-1);
}
From the above example
if(n <=1)
return 1;
Is the deciding factor when to exit the loop
else
return n * fact(n-1);
Is the actual processing to be done
Let me the break the task one by one for easy understanding.
Let us see what happens internally if I run fact(4)
Substituting n=4
public static int fact(4){
if(4 <=1)
return 1;
else
return 4 * fact(4-1);
}
If loop fails so it goes to else loop
so it returns 4 * fact(3)
In stack memory, we have 4 * fact(3)
Substituting n=3
public static int fact(3){
if(3 <=1)
return 1;
else
return 3 * fact(3-1);
}
If loop fails so it goes to else loop
so it returns 3 * fact(2)
Remember we called ```4 * fact(3)``
The output for fact(3) = 3 * fact(2)
So far the stack has 4 * fact(3) = 4 * 3 * fact(2)
In stack memory, we have 4 * 3 * fact(2)
Substituting n=2
public static int fact(2){
if(2 <=1)
return 1;
else
return 2 * fact(2-1);
}
If loop fails so it goes to else loop
so it returns 2 * fact(1)
Remember we called 4 * 3 * fact(2)
The output for fact(2) = 2 * fact(1)
So far the stack has 4 * 3 * fact(2) = 4 * 3 * 2 * fact(1)
In stack memory, we have 4 * 3 * 2 * fact(1)
Substituting n=1
public static int fact(1){
if(1 <=1)
return 1;
else
return 1 * fact(1-1);
}
If loop is true
so it returns 1
Remember we called 4 * 3 * 2 * fact(1)
The output for fact(1) = 1
So far the stack has 4 * 3 * 2 * fact(1) = 4 * 3 * 2 * 1
Finally, the result of fact(4) = 4 * 3 * 2 * 1 = 24
The Tail Recursion would be
public static int fact(x, running_total=1) {
if (x==1) {
return running_total;
} else {
return fact(x-1, running_total*x);
}
}
Substituting n=4
public static int fact(4, running_total=1) {
if (x==1) {
return running_total;
} else {
return fact(4-1, running_total*4);
}
}
If loop fails so it goes to else loop
so it returns fact(3, 4)
In stack memory, we have fact(3, 4)
Substituting n=3
public static int fact(3, running_total=4) {
if (x==1) {
return running_total;
} else {
return fact(3-1, 4*3);
}
}
If loop fails so it goes to else loop
so it returns fact(2, 12)
In stack memory, we have fact(2, 12)
Substituting n=2
public static int fact(2, running_total=12) {
if (x==1) {
return running_total;
} else {
return fact(2-1, 12*2);
}
}
If loop fails so it goes to else loop
so it returns fact(1, 24)
In stack memory, we have fact(1, 24)
Substituting n=1
public static int fact(1, running_total=24) {
if (x==1) {
return running_total;
} else {
return fact(1-1, 24*1);
}
}
If loop is true
so it returns running_total
The output for running_total = 24
Finally, the result of fact(4,1) = 24
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);
}
I'm not a Lisp programmer, but I think this will help.
Basically it's a style of programming such that the recursive call is the last thing you do.
Here is a Common Lisp example that does factorials using tail-recursion. Due to the stack-less 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))
A tail recursive function is a recursive function where the last operation it does before returning is make the recursive function call. That is, the return value of the recursive function call is immediately returned. For example, your code would look like this:
def recursiveFunction(some_params):
# some code here
return recursiveFunction(some_args)
# no code after the return statement
Compilers and interpreters that implement tail call optimization or tail call elimination can optimize recursive code to prevent stack overflows. If your compiler or interpreter doesn't implement tail call optimization (such as the CPython interpreter) there is no additional benefit to writing your code this way.
For example, this is a standard recursive factorial function in Python:
def factorial(number):
if number == 1:
# BASE CASE
return 1
else:
# RECURSIVE CASE
# Note that `number *` happens *after* the recursive call.
# This means that this is *not* tail call recursion.
return number * factorial(number - 1)
And this is a tail call recursive version of the factorial function:
def factorial(number, accumulator=1):
if number == 0:
# BASE CASE
return accumulator
else:
# RECURSIVE CASE
# There's no code after the recursive call.
# This is tail call recursion:
return factorial(number - 1, number * accumulator)
print(factorial(5))
(Note that even though this is Python code, the CPython interpreter doesn't do tail call optimization, so arranging your code like this confers no runtime benefit.)
You may have to make your code a bit more unreadable to make use of tail call optimization, as shown in the factorial example. (For example, the base case is now a bit unintuitive, and the accumulator parameter is effectively used as a sort of global variable.)
But the benefit of tail call optimization is that it prevents stack overflow errors. (I'll note that you can get this same benefit by using an iterative algorithm instead of a recursive one.)
Stack overflows are caused when the call stack has had too many frame objects pushed onto. A frame object is pushed onto the call stack when a function is called, and popped off the call stack when the function returns. Frame objects contain info such as local variables and what line of code to return to when the function returns.
If your recursive function makes too many recursive calls without returning, the call stack can exceed its frame object limit. (The number varies by platform; in Python it is 1000 frame objects by default.) This causes a stack overflow error. (Hey, that's where the name of this website comes from!)
However, if the last thing your recursive function does is make the recursive call and return its return value, then there's no reason it needs to keep the current frame object needs to stay on the call stack. After all, if there's no code after the recursive function call, there's no reason to hang on to the current frame object's local variables. So we can get rid of the current frame object immediately rather than keep it on the call stack. The end result of this is that your call stack doesn't grow in size, and thus cannot stack overflow.
A compiler or interpreter must have tail call optimization as a feature for it to be able to recognize when tail call optimization can be applied. Even then, you may have rearrange the code in your recursive function to make use of tail call optimization, and it's up to you if this potential decrease in readability is worth the optimization.
In short, a tail recursion has the recursive call as the last statement in the function so that it doesn't have to wait for the recursive call.
So this is a tail recursion i.e. N(x - 1, p * x) is the last statement in the function where the compiler is clever to figure out that it can be optimised to a for-loop (factorial). The second parameter p carries the intermediate product value.
function N(x, p) {
return x == 1 ? p : N(x - 1, p * x);
}
This is the non-tail-recursive way of writing the above factorial function (although some C++ compilers may be able to optimise it anyway).
function N(x) {
return x == 1 ? 1 : x * N(x - 1);
}
but this is not:
function F(x) {
if (x == 1) return 0;
if (x == 2) return 1;
return F(x - 1) + F(x - 2);
}
I did write a long post titled "Understanding Tail Recursion – Visual Studio C++ – Assembly View"
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(n-1)
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,n-1);
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.
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;
#_ = ($x-1,$running_total+$x);
goto &tail_rec_sum; # throw away current stack frame
}
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 fact-iter 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 special-purpose “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 tail-recursive. With a
tail-recursive implementation, iteration can be expressed using the
ordinary procedure call mechanism, so that special iteration
constructs are useful only as syntactic sugar.
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 tail-recursive if the stack does not grow infinitely.
Tail Recursion is pretty fast as compared to normal recursion.
It is fast because the output of the ancestors call will not be written in stack to keep the track.
But in normal recursion all the ancestor calls output written in stack to keep the track.
To understand some of the core differences between tail-call recursion and non-tail-call recursion we can explore the .NET implementations of these techniques.
Here is an article with some examples in C#, F#, and C++\CLI: Adventures in Tail Recursion in C#, F#, and C++\CLI.
C# does not optimize for tail-call recursion whereas F# does.
The differences of principle involve loops vs. Lambda calculus. C# is designed with loops in mind whereas F# is built from the principles of Lambda calculus. For a very good (and free) book on the principles of Lambda calculus, see Structure and Interpretation of Computer Programs, by Abelson, Sussman, and Sussman.
Regarding tail calls in F#, for a very good introductory article, see Detailed Introduction to Tail Calls in F#. Finally, here is an article that covers the difference between non-tail recursion and tail-call recursion (in F#): Tail-recursion vs. non-tail recursion in F sharp.
If you want to read about some of the design differences of tail-call recursion between C# and F#, see Generating Tail-Call Opcode in C# and F#.
If you care enough to want to know what conditions prevent the C# compiler from performing tail-call optimizations, see this article: JIT CLR tail-call conditions.
Recursion means a function calling itself. For example:
(define (un-ended name)
(un-ended 'me)
(print "How can I get here?"))
Tail-Recursion means the recursion that conclude the function:
(define (un-ended name)
(print "hello")
(un-ended 'me))
See, the last thing un-ended function (procedure, in Scheme jargon) does is to call itself. Another (more useful) example is:
(define (map lst op)
(define (helper done left)
(if (nil? left)
done
(helper (cons (op (car left))
done)
(cdr left))))
(reverse (helper '() lst)))
In the helper procedure, the LAST thing it does if the left is not nil is to call itself (AFTER cons something and cdr something). This is basically how you map a list.
The tail-recursion has a great advantage that the interpreter (or compiler, dependent on the language and vendor) can optimize it, and transform it into something equivalent to a while loop. As matter of fact, in Scheme tradition, most "for" and "while" loop is done in a tail-recursion manner (there is no for and while, as far as I know).
Tail Recursive Function is a recursive function in which recursive call is the last executed thing in the function.
Regular recursive function, we have stack and everytime we invoke a recursive function within that recursive function, adds another layer to our call stack. In normal recursion
space: O(n) tail recursion makes space complexity from
O(N)=>O(1)
Tail call optimization means that it is possible to call a function from another function without growing the call stack.
We should write tail recursion in recursive solutions. but certain languages do not actually support the tail recursion in their engine that compiles the language down. since ecma6, there has been tail recursion that was in the specification. BUt none of the engines that compile js have implemented tail recursion into it. you wont achieve O(1) in js, because the compiler itself does not know how to implement this tail recursion. As of January 1, 2020 Safari is the only browser that supports tail call optimization.
Haskell and Java have tail recursion optimization
Regular Recursive Factorial
function Factorial(x) {
//Base case x<=1
if (x <= 1) {
return 1;
} else {
// x is waiting for the return value of Factorial(x-1)
// the last thing we do is NOT applying the recursive call
// after recursive call we still have to multiply.
return x * Factorial(x - 1);
}
}
we have 4 calls in our call stack.
Factorial(4); // waiting in the memory for Factorial(3)
4 * Factorial(3); // waiting in the memory for Factorial(2)
4 * (3 * Factorial(2)); // waiting in the memory for Factorial(1)
4 * (3 * (2 * Factorial(1)));
4 * (3 * (2 * 1));
We are making 4 Factorial() calls, space is O(n)
this mmight cause Stackoverflow
Tail Recursive Factorial
function tailFactorial(x, totalSoFar = 1) {
//Base Case: x===0. In recursion there must be base case. Otherwise they will never stop
if (x === 0) {
return totalSoFar;
} else {
// there is nothing waiting for tailFactorial to complete. we are returning another instance of tailFactorial()
// we are not doing any additional computaion with what we get back from this recursive call
return tailFactorial(x - 1, totalSoFar * x);
}
}
We dont need to remember anything after we make our recursive call
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.
A function is tail recursive if each recursive case consists only of a call to the function itself, possibly with different arguments. Or, tail recursion is recursion with no pending work. Note that this is a programming-language independent concept.
Consider the function defined as:
g(a, b, n) = a * b^n
A possible tail-recursive formulation is:
g(a, b, n) | n is zero = a
| n is odd = g(a*b, b, n-1)
| otherwise = g(a, b*b, n/2)
If you examine each RHS of g(...) that involves a recursive case, you'll find that the whole body of the RHS is a call to g(...), and only that. This definition is tail recursive.
For comparison, a non-tail-recursive formulation might be:
g'(a, b, n) = a * f(b, n)
f(b, n) | n is zero = 1
| n is odd = f(b, n-1) * b
| otherwise = f(b, n/2) ^ 2
Each recursive case in f(...) has some pending work that needs to happen after the recursive call.
Note that when we went from g' to g, we made essential use of associativity
(and commutativity) of multiplication. This is not an accident, and most cases where you will need to transform recursion to tail-recursion will make use of such properties: if we want to eagerly do some work rather than leave it pending, we have to use something like associativity to prove that the answer will be the same.
Tail recursive calls can be implemented with a backwards jump, as opposed to using a stack for normal recursive calls. Note that detecting a tail call, or emitting a backwards jump is usually straightforward. However, it is often hard to rearrange the arguments such that the backwards jump is possible. Since this optimization is not free, language implementations can choose not to implement this optimization, or require opt-in by marking recursive calls with a 'tailcall' instruction and/or choosing a higher optimization setting.
Some languages (e.g. Scheme) do, however, require all implementations to optimize tail-recursive functions, maybe even all calls in tail position.
Backwards jumps are usually abstracted as a (while) loop in most imperative languages, and tail-recursion, when optimized to a backwards jump, is isomorphic to looping.
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 heap-allocated 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 heap-allocated 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 both E1 and E2 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, "self-tail 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. stack-based 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 sub-expression argument in a tail call, 5. reducing the environment of a closure to just the free variables of that closure, and 6. so-called "safe-for-space" 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.)
Many people have already explained recursion here. I would like to cite a couple of thoughts about some advantages that recursion gives from the book “Concurrency in .NET, Modern patterns of concurrent and parallel programming” by Riccardo Terrell:
“Functional recursion is the natural way to iterate in FP because it
avoids mutation of state. During each iteration, a new value is passed
into the loop constructor instead to be updated (mutated). In
addition, a recursive function can be composed, making your program
more modular, as well as introducing opportunities to exploit
parallelization."
Here also are some interesting notes from the same book about tail recursion:
Tail-call recursion is a technique that converts a regular recursive
function into an optimized version that can handle large inputs
without any risks and side effects.
NOTE The primary reason for a tail call as an optimization is to
improve data locality, memory usage, and cache usage. By doing a tail
call, the callee uses the same stack space as the caller. This reduces
memory pressure. It marginally improves the cache because the same
memory is reused for subsequent callers and can stay in the cache,
rather than evicting an older cache line to make room for a new cache
line.
I am new to C and I'm reading about recursion, but I am totally confused.
The main part where I'm getting confused is how things get unwind when the exit condition is reached. I would like to know how during recursion values got pushed and popped from stack.
Also can anyone please give me a diagramatic view of recursion?
Thanks...
Lets assume a function:
int MyFunc(int counter) {
// check this functions counter value from the stack (most recent push)
// if counter is 0, we've reached the terminating condition, return it
if(counter == 0) {
return counter;
}
else {
// terminating condition not reached, push (counter-1) onto stack and recurse
int valueToPrint = MyFunc(counter - 1);
// print out the value returned by the recursive call
printf("%d", valueToPrint);
// return the value that was supplied to use
// (usually done via a register I think)
return counter;
}
}
int main() {
// Push 9 onto the stack, we don't care about the return value...
MyFunc(9);
}
The output is: 012345678
The first time through MyFunc, count is 9. It fails the terminating check (it is not 0), so the recursive call is invoked, with (counter -1), 8.
This repeats, decrementing the value pushed onto the stack each time until counter == 0. At this point, the terminating clause fires and the function simply returns the value of counter (0), usually in a register.
The next call up the stack, uses the returned value to print (0), then returns the value that was supplied into it when it was called (1). This repeats:
The next call up the stack, uses the returned value to print (1), then returns the value that was supplied into it when it was called (2). etc, till you get to the top of the stack.
So, if MyFunc was invoked with 3, you'd get the equivalent of (ignoring return addresses etc from the stack):
Call MyFunc(3) Stack: [3]
Call MyFunc(2) Stack: [2,3]
Call MyFunc(1) Stack: [1,2,3]
Call MyFunc(0) Stack: [0,1,2,3]
Termination fires (top of stack == 0), return top of stack(0).
// Flow returns to:
MyFunc(1) Stack: [1,2,3]
Print returned value (0)
return current top of stack (1)
// Flow returns to:
MyFunc(2) Stack: [2,3]
Print returned value (1)
return current top of stack (2)
// Flow returns to:
MyFunc(3) Stack: [3]
Print returned value (2)
return current top of stack (3)
// and you're done...
How things get unwind when the exit condition is reached?
First, few words about recursion: a divide and conquer method used for complex tasks that can be gradually decomposed and reduced to a simple instances of the initial task until a form(base case) that allows direct calculation is reached. It is a notion closely related to mathematical induction.
More specifically, a recursive function calls itself, either directly or indirectly. In direct recursion function, foo(), makes another call to itself. In indirect recursion, function foo() makes a call to function moo(), which in turn calls function foo(), until the base case is reached, and then, the final result is accumulated in the exact reverse order of the initial recursive function call.
Example:
Factorial n, denoted n!, is the product of positive integers from 1 to n. The factorial can be formally defined as: factorial(0)=1, (base case) factorial(n)= n * factorial(n-1), for n > 0. (recursive call)
Recursion shows up in this definition as we define factrorial(n) in terms of factorial(n-1).
Every recursion function should have termination condition to end recursion. In this example, when n=0, recursion stops. The above function expressed in C is:
int fact(int n){
if(n == 0){
return 1;
}
return (n * fact(n-1));
}
This example is an example of direct recursion.
How is this implemented? At the software level, its implementation is not different from implementing other functions(procedures). Once you understand that each procedure call instance is distinct from the others, the fact that a recursive function calls itself does not make any big difference.
Each active procedure maintains an activation record, which is stored on the stack. The activation record consists of the arguments, return address (of the caller), and local variables.
The activation record comes into existence when a procedure is invoked and disappears after the procedure is terminated and the result is returned to the caller. Thus, for each procedure that is not terminated, an activation record that contains the state of that procedure is stored. The number of activation records, and hence the amount of stack space required to run the program, depends on the depth of recursion.
Also can anyone please give me a diagramatic view of recursion?
Next figure shows the activation record for factorial(3):
As you can see from the figure, each call to the factorial creates an activation record until the base case is reached and starting from there we accumulate the result in the form of product.
In C recursion is just like ordinary function calls.
When a function is called, the arguments, return address, and frame pointer (I forgot the order) are pushed on the stack.
In the called function, first the space for local variables is "pushed" on the stack.
if function returns something, put it in a certain register (depends on architecture, AFAIK)
undo step 2.
undo step 1.
So, with recursion steps 1 and 2 are performed a few times, then possibly 3 (maybe only once) and finally 4 and 5 are done (as many times as 1 and 2).
An alternative answer is that in general you don't know. C as a language doesn't have any stack of heap. Your compiler uses a memory location called the stack to store control flow information such as stack frames, return addresses and registers, but there is nothing in C prohibiting the compiler to store that information elsewhere. For practical aspects the previous answers are correct. This is how C compilers operate today.
This question has been widely answered. Allow me please to incorporate an additional answer using a more pedagogical approach.
You can think function recursion as a stack of bubbles with two differentiate stages: pushing stage and bursting stage.
A) PUSHING STAGE (or "Pushing the stack", as OP call it)
0) The starting Bubble #0 is the MAIN function. It is blown up with this information:
Local variables.
The call to the next Bubble #1 (the first call to the recursive
function, MYFUNC).
1) Bubble #1 is blown up on its turn with this information:
Parameters from the previous Bubble #0.
Local variables if necessary.
A returning address.
Terminating check with a returning value (eg: if (counter == 0) {return 1}).
A call to the next Bubble #2.
Remember that this bubble, as the other bubbles, is the recursive function MYFUNC.
2) Bubble #2 is blown up with the same information as Bubble #1, getting from the latter the necessary input (parameters). After this point, you can stack as many bubbles as you want inflating the information accordingly to the listed items in Bubble #1.
i) So you get as many bubbles as you want: Bubble #3, Bubble #4..., Bubble #i. The very last bubble has a NAIL in the terminating check. Be aware!
B) BURSTING STAGE (or "Popping the stack", as OP call it)
This stage happens when you reach the positive terminating check and the last bubble containing the nail is burst.
Let's say this stage happens in Bubble #3. The positive terminating check is reached and Bubble #3 is burst. Then the NAIL from this bubble is liberated. This nail falls on the underneath Bubble #2 and burst it. After this happens the nail follows its fall until it burst Bubble #1. The same happens to Bubble #0. It is important to notice that the nail follows the returning address in the bubble that it's being burst at the moment: the address tells the nail which direction to follow while falling.
At the end of this process, the answer is obtained and delivered to the MAIN function (or Bubble #0, which of course is not burst).
C) GRAPHICALLY (as OP asked)
This is the graphical explanation. It evolves from the bottom, Bubble #0 to top, Bubble #3.
/*Bubble #3 (MYFUNC recursive function): Parameters from Bubble #2,
local variables, returning address, terminating check (NAIL),
call (not used here, as terminating check is positive).*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #2
/*Bubble #2 (MYFUNC recursive function): Parameters from Bubble #1,
local variables, returning address, terminating check (not used),
call to Bubble #3.*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #1
/*Bubble #1 (MYFUNC recursive function): Parameters from Bubble #0,
local variables, returning address, terminating check (not used),
call to Bubble #2.*/
Pushing up to the bubble above ↑ ----------------------------------------------------- 🡓 Nail falls to Bubble #0
/*Bubble #0 (MAIN function): local variables, the first call to Bubble #1.*/
Hope this approach helps someone. Let me know if any clarification is needed.