A couple of questions on recursive functions in C language - c

This is a function to get sum of the digits of a number:
int sumOfDigits(int n)
{
int sum=0; //line 1
if(n==0)
return sum;
else
{
sum=(n%10)+sumOfDigits(n/10); //line 2
// return sum; //line 3
}
}
While writing this code, I realized the scope of the local variables is local to each individual recursion of the function. So am I right in saying that if n=11111, 5 sum variables are created and pushed on the stack with each recursion? If this is correct then what is the benefit of using recursion when I can do it in normal function using loops, thus overwriting only one memory location? If I use pointers, recursion will probably take similar memory as a normal function.
Now my second question, even though this function gives me the correct result each time, I don't see how the recursions (other than the last one which returns 0) return values without uncommenting line 3. (using geany with gcc)
I'm new to programming, so please pardon any mistakes

So am I right in saying that if n=11111, 5 sum variables are created and pushed on the stack with each recursion?
Conceptually, but compilers may turn some forms of recursion into jumps/loops. E.g. a compiler that does tail call optimization may turn
void rec(int i)
{
if (i > 0) {
printf("Hello, level %d!\n", i);
rec(i - 1);
}
}
into the equivalent of
void loop(int i)
{
for (; i > 0; i--)
printf("Hello, level %d!\n", i);
}
because the recursive call is in tail position: when the call is made, the current invocation of rec has no more work to do except a return to its caller, so it might as well reuse its stack frame for the next recursive call.
If this is correct then what is the benefit of using recursion when I can do it in normal function using loops, thus overwriting only one memory location? If I use pointers, recursion will probably take similar memory as a normal function.
For this problem, recursion is a pretty bad fit, at least in C, because a loop is much more readable. There are problems, however, where recursion is easier to understand. Algorithms on tree structures are the prime example.
(Although every recursion can be emulated by a loop with an explicit stack, and then stack overflows can be more easily caught and handled.)
I don't understand the remark about pointers.
I don't see how the recursions (other than the last one which returns 0) return values without uncommenting line 3.
By chance. The program exhibits undefined behavior, so it may do anything, even return the correct answer.

So am I right in saying that if n=11111, 5 sum variables are created
and pushed on the stack with each recursion?
The recursion is 5 levels deep, so traditionally 5 stack frames will be eventually created (but read below!), each one of which will have space to hold a sum variable. So this is mostly correct in spirit.
If this is correct then what is the benefit of using recursion when I
can do it in normal function using loops, thus overwriting only one
memory location?
There are several reasons, which include:
it might be more natural to express an algorithm recursively; if the performance is acceptable, maintainability counts for a lot
simple recursive solutions typically do not keep state, which means they are trivially parallelizable, which is a major advantage in the multicore era
compiler optimizations frequently negate the drawbacks of recursion
I don't see how the recursions (other than the last one which returns
0) return values without uncommenting line 3.
It's undefined behavior to comment out line 3. Why would you do that?

Yes, the parameters and local variables are local to each invokation and this is usually achieved by creating a copy of each invokation variables set on the program stack. Yes, that consumes more memory compared to an implementation with a loop, but only if the problem can be solved with a loop and constant memory usage. Consider traversing a tree - you will have to store the tree elements somewhere - be it on the stack or in some other structure. Recursion advantage is it is easier to implement (but not always easier to debug).
If you comment return sum; in the second branch the behavior is undefined - anything can happen, expected behavior included. That's not what you should do.

Related

Can this code be called Recursion. If not, which is more advanatgeous, given below code or recursion?

I am having difficulty finding how recursion works. Some text books
says that "Recursion is when a function calls itself again and again
until some base condition is satisfied".
Some books says that "Recursion is when a function calls another
function again and again till some base condition is satisfied".
Which is true? If both are true, can we consider below given example
as a Recursion? If NO, then which is better in terms of performance,
below code or recursion?
def Function1()
{
/* do something */
}
def Function2()
{
for(i=0; i<=10; i++)
{
call Function1()
}
}
As it is, the code shows iterative calls to Function1(), if within the body of Function1() there is a call to Function2(), then it would be an indirect recursion - a function calling second function, which then calls the first again.
In general, 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.)
Now, to answer your question:
Can this code be called Recursion. If not, which is more advanatgeous, given below code or recursion?
No. Iteration lacks multiple activation records (or stack frames), which makes it a better alternative.
Recursion should be used according to requirement and when you know the base condition and don't know how many times your loop should be called.
Recursion can be of different types like there can be normal recursion, infinite recursion, indirect recursion etc.
A normal recursion means calling the same function itself until a base condition is satisfied
An infinite recursion is where there will not be any base condition.
An indirect recursion is like when a calls b and b calls c and c calls back a then 'a' is being called indirectly.
Example of basic recursion:
foo()
{
base_condition;
return;
foo();
}
main()
{
foo();
}
Your example base condition can be variable equals runs for 10 times.
fun(int x)
{
if(x == 0)
return;
fun(--x);
}
main
{
fun(10);
}
Please look into the below URL for performance criteria.
performance between looping and recursion
Recursion is when
The control flow passes from a function into the very same function (directly or indirectly) repeatedly without returning first.
In your example, Function1is repeatedly called from Function2, but does return from each call before being called again, so it's not recursively called.
Let me put the pieces together: The code you provided could be recursive or it couldn't. This depends on the fact whether Function1 calls Function2. If this is the case, then you would have a mutual exclusion recursion, as pointed out by EOF.
However, this is a case that does not occur as often as normal recursion (except in pure functional environments). A normal recursion simply consists of a function which calls itself (insteaf of another function).
For further explanations and an introduction how, e. g., the recursive factorial works, see here.
Recursion occurs when a thing is defined in terms of itself or of its
type. Recursion is used in a variety of disciplines ranging from
linguistics to logic. The most common application of recursion is in
mathematics and computer science, where a function being defined is
applied within its own definition. While this apparently defines an
infinite number of instances (function values), it is often done in
such a way that no loop or infinite chain of references can occur.
Source.
So, if you have a foo and in order to calculate or execute foo, you need to recur to foo at least once more, then you have a recursion. Example:
n! = 1 * 2 * 3 * ... * n
This is an iterative definition:
int fact(n) {
int ret = 1;
int i = 1;
while (++i < n) ret *= i;
return ret;
}
This is a recursive definition:
int fact(n) {
return (n == 1) ? 1 : (n * fact(n - 1));
}
Since your code calculates Function2 with multiple usages of Function1, it is not recursive, since you did not need to call Function2 in order to evaluate Function2, nor did you need to call Function1 in order to evaluate Function1. Recursion occurs when something is its own dependency, while your code has a function which depends on another function. Your question about performance is next to impossible to answer, since there are infinite ways to implement a thing with or without recursion, when you compare a recursive approach with a non-recursive approach, then you need to have concrete implementations, or at least very strict ideas of how the two cases would be implemented. However, in general it is a good idea to prefer non-recursive approaches, as recursive approaches often have problems with the stack part of the memory, including stack overflow or infinite function calls and crashes due to bugs.
Recursion is when a function calls itself, either directly or indirectly.
Normally in the C-like languages we use recursion only when the data is tree-like. For example, you have a tree consisting of nodes, with a "next" member to indicate siblings and a "child" member to indicate children (maybe it's an XML file, or a directory tree). You want the the number of nodes so
int getNodes(Node root)
{
int answer = 1;
for(sib = root.next; sib != null; sib = sib.next)
{
answer += 1;
if(sib.child != null)
answer += getNnodes(sib.child);
}
if(node.child != null)
answer += getNodes(node.child);
return answer;
}
You can make the code a bit neater but less efficient by return 0 if root == null.
However you can use recursion for iteration. Think of it as delivering letters to a street. You can go down the street removing letters from your sack (iteration). Or you can deliver letters to the first house in the street, declare the street to be one house shorter, and repeat until the street disappears (recursion). The latter seems eccentric, but it has some advantages for automatic checking of algorithm correctness. If you forget to increment it you can't get stuck in an infinite loop, for example.

Can repeated calls to the same function provide better performance?

I have code that looks like this:
void foo(unsigned long k)
{
if (k & 1)
{
bar(k/2 + 1);
bar(k/2);
bar(k/2 + 1);
}
else
{
bar(k/2);
bar(k/2);
bar(k/2);
}
}
void bar(unsigned long k)
{
switch(k)
{
case default: special_default(); break;
case 1: specialbar1(); break;
case 2: specialbar2(); break;
<more cases>
case 16: specialbar16(); break;
}
}
The performance is much better when foo is called for an even value of k. Each of the specialbar#() methods uses several stack variables, the number of such variables increases sharply as k increases. To be clear specialbar#() makes use of about 3 * k local variables all of which are unsigned long long variables.
For example foo(32) executes about 15% faster than foo(31). I am using Visual Studio 2012 and the performance analysis assures me that two calls to specialbar16 and one call to specialbar15 takes considerably more work than three consecutive calls to specialbar16.
Is it possible that the compiler takes advantage of the three consecutive calls when k is even? That is, can it realize that the stack is essentially the same over the three consecutive calls for even k yet the same optimization is not possible for odd k?
Is it possible that the compiler takes advantage of the three consecutive calls when k is even? That is can it realize that the stack is essentially the same over the three consecutive calls for even k yet the same optimization is not possible for odd k?
This hardly seems worthy of an answer but, yes, that's entirely possible. The compiler may recognize that the same stack layout is required for each call due it it being the same method each time, and thus avoid the whole stack setup/teardown for each method call. It is in this case probably also inlining the method call - the code is generated in place in the caller.
Most likely similar optimization could be performed for the other case as well, though optimization is tricky and there are sometimes subtle reasons why a compiler won't be able to perform it.
You're foo function performs extra logic when k is odd (k/2 + 1) the + 1.
To answer your specific question, can repeated calls improve performance. Yes it can when the parameters are the same the tranches within the function are the same and this allows for "branch prediction" to work optimally.

Is there any hard-wired limit on recursion depth in C

The program under discussion attempts to compute sum-of-first-n-natural-numbers using recursion. I know this can be done using a simple formula n*(n+1)/2 but the idea here is to use recursion.
The program is as follows:
#include <stdio.h>
unsigned long int add(unsigned long int n)
{
return (n == 0) ? 0 : n + add(n-1);
}
int main()
{
printf("result : %lu \n", add(1000000));
return 0;
}
The program worked well for n = 100,000 but when the value of n was increased to 1,000,000 it resulted in a Segmentation fault (core dumped)
The following was taken from the gdb message.
Program received signal SIGSEGV, Segmentation fault.
0x00000000004004cc in add (n=Cannot access memory at address 0x7fffff7feff8
) at k.c:4
My question(s):
Is there any hard-wired limit on recursion depth in C? or does the recursion depth depends on the available stack memory?
What are the possible reasons why a program would receive a reSIGSEGV signal?
Generally the limit will be the size of the stack. Each time you call a function, a certain amount of stack is eaten (usually dependent on the function). The eaten amount is the stack frame, and it is recovered when the function returns. The stack size is almost almost fixed when the program starts, either from being specified by the operating system (and often adjustable there), or even being hardcoded in the program.
Some implementations may have a technique where they can allocate new stack segments at run time. But in general, they don't.
Some functions will consume stack in slightly more unpredictable ways, such as when they allocate a variable-length array there.
Some functions may be compiled to use tail-calls in a way that will preserve stack space. Sometimes you can rewrite your function so that all calls (Such as to itself) happen as the last thing it does, and expect your compiler to optimise it.
It's not that easy to see exactly how much stack space is needed for each call to a function, and it will be subject to the optimisation level of the compiler. A cheap way to do that in your case would be to print &n each time its called; n will likely be on the stack (especially since the progam needs to take its address -- otherwise it could be in a register), and the distance between successive locations of it will indicate the size of the stack frame.
1)Consumption of the stack is expected to be reduced and written as tail recursion optimization.
gcc -O3 prog.c
#include <stdio.h>
unsigned long long int add(unsigned long int n, unsigned long long int sum){
return (n == 0) ? sum : add(n-1, n+sum); //tail recursion form
}
int main(){
printf("result : %llu \n", add(1000000, 0));//OK
return 0;
}
There is no theoretical limit to recursion depth in C. The only limits are those of your implementation, generally limited stack space.
(Note that the C standard doesn't actually require a stack-based implementation. I don't know of any real-world implementations that aren't stack based, but keep that in mind.)
A SIGSEGV can be caused by any number of things, but exceeding your stack limit is a relatively common one. Dereferencing a bad pointer is another.
The C standard does not define the minimum supported depth for function calls. If it did, which is quite hard to guarantee anyway, it would have it mentioned somewhere in section 5.2.4 Environmental limits.

Is there a way to reference the function you are inside of in C?

I am writing a function that just looks up values inside of a table. Is it possible to call that function inside of itself? I've seen stuff about this and self and don't really understand it.
Yes, you can. It's called recursion.
void foo(){
foo(); //This is legal.
}
Of course you need to return from it to avoid infinite recursive calls. Failing to return will cause a stack overflow. Here's a better example:
void foo(int n){
if (n == 0)
return;
foo(--n);
}
See Recursion (computer science) (Wikipedia).
An example of calling a function inside a function:
# include<stdio.h>
int factorial(unsigned int number)
{
if (number <= 1)
return 1;
return number * factorial(number - 1);
}
void main()
{
int x = 5;
printf("factorial of %d is %d",x,factorial(x));
}
Others have answered your question, but since it was alien to you, you might want to read up on recursion and recursive functions. There are some gotchas that may catch you if you are not aware.
The worst of which is that you can quickly overflow your stack if you are too deep, or if your function stack-allocates a lot of things. If you are planning to use a recursive implementation make sure your recursion is bounded and that you allocate the bare minimum on the stack.
You might want to consider an iterative approach - every recursive problem can be solved iteratively with some thought. It's usually an interesting exercise to do as well.
JoshLeaves has said that recursion is faster, but often it's not because of the need to allocate grow stack and set up registers. If your function makes two or more calls to itself to calculate its result then an iterative solution is always faster.
Update
Okay, I thought this was about "getting every function value". As other posters said, this is called recursion. A few notes though:
Recursion is faster than iteration (I don't have benchmark results on hand, but I ran them one year ago on an Intel Core i5).
//Iteration
function do_stuff(i)
{
//BLABLAH
}
for (i = 0; i <5; i++) {
do_stuff();
}
//Recursion
function do_stuff(int i)
{
//BLABLAH
if (i < 5) {
do_stuff(i + 1);
}
}
You can recurse multiple times but you have to find a way to make the recursion stop or...
If your recursion goes down too far (think "Inception" times a million...), you run into the risk of overflowing your available stack memory just by entering the same function a millionth time.

What is the most elegant way to loop TWICE in C

Many times I need to do things TWICE in a for loop. Simply I can set up a for loop with an iterator and go through it twice:
for (i = 0; i < 2; i++)
{
// Do stuff
}
Now I am interested in doing this as SIMPLY as I can, perhaps without an initializer or iterator? Are there any other, really simple and elegant, ways of achieving this?
This is elegant because it looks like a triangle; and triangles are elegant.
i = 0;
here: dostuff();
i++; if ( i == 1 ) goto here;
Encapsulate it in a function and call it twice.
void do_stuff() {
// Do Stuff
}
// .....
do_stuff();
do_stuff();
Note: if you use variables or parameters of the enclosing function in the stuff logic, you can pass them as arguments to the extracted do_stuff function.
If its only twice, and you want to avoid a loop, just write the darn thing twice.
statement1;
statement1; // (again)
If the loop is too verbose for you, you can also define an alias for it:
#define TWICE for (int _index = 0; _index < 2; _index++)
This would result into that code:
TWICE {
// Do Stuff
}
// or
TWICE
func();
I would only recommend to use this macro if you have to do this very often, I think else the plain for-loop is more readable.
Unfortunately, this is not for C, but for C++ only, but does exactly what you want:
Just include the header, and you can write something like this:
10 times {
// Do stuff
}
I'll try to rewrite it for C as well.
So, after some time, here's an approach that enables you to write the following in pure C:
2 times {
do_something()
}
Example:
You'll have to include this little thing as a simple header file (I always called the file extension.h). Then, you'll be able to write programs in the style of:
#include<stdio.h>
#include"extension.h"
int main(int argc, char** argv){
3 times printf("Hello.\n");
3 times printf("Score: 0 : %d\n", _);
2 times {
printf("Counting: ");
9 times printf("%d ", _);
printf("\n");
}
5 times {
printf("Counting up to %d: ", _);
_ times printf("%d ", _);
printf("\n");
}
return 0;
}
Features:
Simple notation of simple loops (in the style depicted above)
Counter is implicitly stored in a variable called _ (a simple underscore).
Nesting of loops allowed.
Restrictions (and how to (partially) circumvent them):
Works only for a certain number of loops (which is - "of course" - reasonable, since you only would want to use such a thing for "small" loops). Current implementation supports a maximum of 18 iterations (higher values result in undefined behaviour). Can be adjusted in header file by changing the size of array _A.
Only a certain nesting depth is allowed. Current implementation supports a nesting depth of 10. Can be adjusted by redefining the macro _Y.
Explanation:
You can see the full (=de-obfuscated) source-code here. Let's say we want to allow up to 18 loops.
Retrieving upper iteration bound: The basic idea is to have an array of chars that are initially all set to 0 (this is the array counterarray). If we issue a call to e.g. 2 times {do_it;}, the macro times shall set the second element of counterarray to 1 (i.e. counterarray[2] = 1). In C, it is possible to swap index and array name in such an assignment, so we can write 2[counterarray] = 1 to acchieve the same. This is exactly what the macro times does as first step. Then, we can later scan the array counterarray until we find an element that is not 0, but 1. The corresponding index is then the upper iteration bound. It is stored in variable searcher. Since we want to support nesting, we have to store the upper bound for each nesting depth separately, this is done by searchermax[depth]=searcher+1.
Adjusting current nesting depth: As said, we want to support nesting of loops, so we have to keep track of the current nesting depth (done in the variable depth). We increment it by one if we start such a loop.
The actual counter variable: We have a "variable" called _ that implicitly gets assigned the current counter. In fact, we store one counter for each nesting depth (all stored in the array counter. Then, _ is just another macro that retrieves the proper counter for the current nesting depth from this array.
The actual for loop: We take the for loop into parts:
We initialize the counter for the current nesting depth to 0 (done by counter[depth] = 0).
The iteration step is the most complicated part: We have to check if the loop at the current nesting depth has reached its end. If so, we have do update the nesting depth accordingly. If not, we have to increment the current nesting depth's counter by 1. The variable lastloop is 1 if this is the last iteration, otherwise 0, and we adjust the current nesting depth accordingly. The main problem here is that we have to write this as a sequence of expressions, all separated by commata, which requires us to write all these conditions in a very non-straight-forward way.
The "increment step" of the for loop consists of only one assignment, that increments the appropriate counter (i.e. the element of counter of the proper nesting depth) and assigns this value to our "counter variable" _.
What about this??
void DostuffFunction(){}
for (unsigned i = 0; i < 2; ++i, DostuffFunction());
Regards,
Pablo.
What abelenky said.
And if your { // Do stuff } is multi-line, make it a function, and call that function -- twice.
Many people suggest writing out the code twice, which is fine if the code is short. There is, however, a size of code block which would be awkward to copy but is not large enough to merit its own function (especially if that function would need an excessive number of parameters). My own normal idiom to run a loop 'n' times is
i = number_of_reps;
do
{
... whatever
} while(--i);
In some measure because I'm frequently coding for an embedded system where the up-counting loop is often inefficient enough to matter, and in some measure because it's easy to see the number of repetitions. Running things twice is a bit awkward because the most efficient coding on my target system
bit rep_flag;
rep_flag = 0;
do
{
...
} while(rep_flag ^= 1); /* Note: if loop runs to completion, leaves rep_flag clear */
doesn't read terribly well. Using a numeric counter suggests the number of reps can be varied arbitrarily, which in many instances won't be the case. Still, a numeric counter is probably the best bet.
As Edsger W. Dijkstra himself put it : "two or more, use a for". No need to be any simpler.
Another attempt:
for(i=2;i--;) /* Do stuff */
This solution has many benefits:
Shortest form possible, I claim (13 chars)
Still, readable
Includes initialization
The amount of repeats ("2") is visible in the code
Can be used as a toggle (1 or 0) inside the body e.g. for alternation
Works with single instruction, instruction body or function call
Flexible (doesn't have to be used only for "doing twice")
Dijkstra compliant ;-)
From comment:
for (i=2; i--; "Do stuff");
Use function:
func();
func();
Or use macro (not recommended):
#define DO_IT_TWICE(A) A; A
DO_IT_TWICE({ x+=cos(123); func(x); })
If your compiler supports this just put the declaration inside the for statement:
for (unsigned i = 0; i < 2; ++i)
{
// Do stuff
}
This is as elegant and efficient as it can be. Modern compilers can do loop unrolling and all that stuff, trust them. If you don't trust them, check the assembler.
And it has one little advantage to all other solutions, for everybody it just reads, "do it twice".
Assuming C++0x lambda support:
template <typename T> void twice(T t)
{
t();
t();
}
twice([](){ /*insert code here*/ });
Or:
twice([]()
{
/*insert code here*/
});
Which doesn't help you since you wanted it for C.
Good rule: three or more, do a for.
I think I read that in Code Complete, but I could be wrong. So in your case you don't need a for loop.
This is the shortest possible without preprocessor/template/duplication tricks:
for(int i=2; i--; ) /*do stuff*/;
Note that the decrement happens once right at the beginning, which is why this will loop precisely twice with the indices 1 and 0 as requested.
Alternatively you can write
for(int i=2; i--; /*do stuff*/) ;
But that's purely a difference of taste.
If what you are doing is somewhat complicated wrap it in a function and call that function twice? (This depends on how many local variables your do stuff code relies on).
You could do something like
void do_stuff(int i){
// do stuff
}
do_stuff(0);
do_stuff(1);
But this may get extremely ugly if you are working on a whole bunch of local variables.
//dostuff
stuff;
//dostuff (Attention I am doing the same stuff for the :**2nd** time)
stuff;
First, use a comment
/* Do the following stuff twice */
then,
1) use the for loop
2) write the statement twice, or
3) write a function and call the function twice
do not use macros, as earlier stated, macros are evil.
(My answer's almost a triangle)
What is elegance? How do you measure it? Is someone paying you to be elegant? If so how do they determine the dollar-to-elegance conversion?
When I ask myself, "how should this be written," I consider the priorities of the person paying me. If I'm being paid to write fast code, control-c, control-v, done. If I'm being paid to write code fast, well.. same thing. If I'm being paid to write code that occupies the smallest amount of space on the screen, I short the stock of my employer.
jump instruction is pretty slow,so if you write the lines one after the other,it would work faster,than writing a loop. but modern compilers are very,very smart and the optimizations are great (if they are allowed,of course). if you have turned on your compiler's optimizations,you don't care the way,you write it - with loop or not (:
EDIT : http://en.wikipedia.org/wiki/compiler_optimizations just take a look (:
Close to your example, elegant and efficient:
for (i = 2; i; --i)
{
/* Do stuff */
}
Here's why I'd recommend that approach:
It initializes the iterator to the number of iterations, which makes intuitive sense.
It uses decrement over increment so that the loop test expression is a comparison to zero (the "i;" can be interpreted as "is i true?" which in C means "is i non-zero"), which may optimize better on certain architectures.
It uses pre-decrement as opposed to post-decrement in the counting expression for the same reason (may optimize better).
It uses a for loop instead of do/while or goto or XOR or switch or macro or any other trick approach because readability and maintainability are more elegant and important than clever hacks.
It doesn't require you to duplicate the code for "Do stuff" so that you can avoid a loop. Duplicated code is an abomination and a maintenance nightmare.
If "Do stuff" is lengthy, move it into a function and give the compiler permission to inline it if beneficial. Then call the function from within the for loop.
I like Chris Case's solution (up here), but C language doesn't have default parameters.
My solution:
bool cy = false;
do {
// Do stuff twice
} while (cy = !cy);
If you want, you could do different things in the two cycle by checking the boolean variable (maybe by ternary operator).
void loopTwice (bool first = true)
{
// Recursion is your friend
if (first) {loopTwice(false);}
// Do Stuff
...
}
I'm sure there's a more elegant way, but this is simple to read, and pretty simply to write. There might even be a way to eliminate the bool parameter, but this is what I came up with in 20 seconds.

Resources