472,103 Members | 1,554 Online

# Reversing digits of an integer using recursion

17
I am writing in C. I want to reverse the input integer using recursion so if the input is 456, the output should be 654. it only needs to work with positive numbers.
I've already written this function but the only output i get for any input is '0'. I know that its the same 0 from sum=0; because when i change 'sum' to any other number at the beginning, that number is outputted. its almost as if the 'if' clause is being skipped completely.
Here is the code:

Expand|Select|Wrap|Line Numbers
1. int reverse(int num)
2. {
3.      int sum,z;
4.      sum=0;
5.      if(num>0)
6.        {
7.        z=num%10;
8.        sum=(sum*10)+z;
9.        reverse(num/10);
10.        }
11.      else
12.        return (sum);
13. }
Aug 23 '08 #1
15 18853
leejwen
50
Aug 23 '08 #2
Banfa
9,065 Expert Mod 8TB
ab12, you have a recursive function yet you never use the return value of that recursion.

The true block of you if statement never returns a value.

The only value actually returned by your function is 0 in the false block of the if statement.
Aug 23 '08 #3
ab12
17
ab12, you have a recursive function yet you never use the return value of that recursion.

The true block of you if statement never returns a value.

The only value actually returned by your function is 0 in the false block of the if statement.
That was kind of the point because eventually i want the function to return whatever the value of sum is...so since thats not working what could i do to fix this problem?
Aug 23 '08 #4
ab12
17
Remove line #11.

kind regards,

Jos
i did that but now if i enter something like 456, my output is only 6
Aug 23 '08 #5
JosAH
11,448 Expert 8TB
i did that but now if i enter something like 456, my output is only 6
I accidentally removed my message while I wanted to edit it; sorry for that.
Your algorithm isn't correct. Check it by hand, e.g. for a number 456 you
want to reverse 56 and append 4 or you want to reverse 45 and prepend 6.
Of course reversing the number 56 or 45 is the recursive step.

kind regards,

Jos
Aug 23 '08 #6
ab12
17
I accidentally removed my message while I wanted to edit it; sorry for that.
Your algorithm isn't correct. Check it by hand, e.g. for a number 456 you
want to reverse 56 and append 4 or you want to reverse 45 and prepend 6.
Of course reversing the number 56 or 45 is the recursive step.

kind regards,

Jos
ok i figured it out. i instead used a while statement. Thanks.
Aug 23 '08 #7
Banfa
9,065 Expert Mod 8TB
I have to say it sounds like you are trying to code the algorithm without actually knowing what it is. That is trying code randomly rather than knowing the algorithm that performs the operation and then writing code the implements the algorithm.

Can you write down the algorithm you are trying to solve?

Also a common gotcha with this algorithm is its ability to handle 0 digits. When you get to testing you should definitely test with a value like 1304.
Aug 23 '08 #8
Banfa
9,065 Expert Mod 8TB
Oops didn't see your last message, glad it's working but I still suggest testing with a 0 digit in the value.
Aug 23 '08 #9
ab12
17
Oops didn't see your last message, glad it's working but I still suggest testing with a 0 digit in the value.
its still works with 0 as a digit, but i was wondering, is this function still recursive if i use a while(n>0) statement? at the end of the while statement i put num=num/10;
Aug 24 '08 #10
Banfa
9,065 Expert Mod 8TB
No it is now iterative.

A function that uses a loop is iterative, that is it iterates (does the same thing again and again).

A function that calls itself is recursive, this is it recurses (calls itself again and again)

A rule of thumb is that it is possible to re-write any recursive function as an iterative function and any iterative function as a recursive one.
Aug 24 '08 #11
NeoPa
32,497 Expert Mod 16PB
Just a small, general, suggestion.

In a case like this, where the procedure itself is pretty basic, it's a good idea to take your code through a dry run.

Take a piece of paper and write out some columns for each of your variables (including one (IP) for an Instruction Pointer - to say where you've reached in the code), and then process through your code as the computer would, and reflect on the paper what is happening. You will very often find that you can see easily where the logic falls down, and get a much better understanding of what's going on in the process.

It would be perfect for a situation like this. The IP value is particularly important when working with recursive functions.

I hope this helps you and welcome to Bytes!
Aug 24 '08 #12
JosAH
11,448 Expert 8TB
Take a piece of paper and write out [ ... ]
As well as reading, pencil and paper are soooo much 20th century and outdated.
We live in a copy and paste society and we demand that it all works instantaneously.
No comprehension is needed nor wanted anymore.

kind regards,

Jos
Aug 24 '08 #13
NeoPa
32,497 Expert Mod 16PB
Just a small, general, suggestion.

In a case like this, where the procedure itself is pretty basic, it's a good idea to take your code through a dry run.

Open up Excel or any spreadsheet program and head up some columns for each of your variables (including one (IP) for an Instruction Pointer - to say where you've reached in the code), and then process through your code as the computer would, and reflect, in the spreadsheet, what is happening. You will very often find that you can see easily where the logic falls down, and get a much better understanding of what's going on in the process.

It would be perfect for a situation like this. The IP value is particularly important when working with recursive functions.

I hope this helps you and welcome to Bytes!
Aug 25 '08 #14
when u call the reverse function again.. the variable sum is every time initialized to zero..! then we dont obtain the reverse of the number !!
Feb 7 '12 #15
NeoPa
32,497 Expert Mod 16PB
It's a local variable (on the stack) so it's only used in the current call of the procedure. As such, there is simply no basis for your statement and it is not true.
Feb 7 '12 #16