thanks a lot to all of you
thanks a lot to all of you
>for example i get 1,2,3 so the combinaions is: 1,3,2 3,1,2 3,2,1
For future reference, combinations and permutations are very different. You want permutations.
>Do it recursively
It's just as easy to do it non-recursively. The factorial example is a good example of a bad way to use recursion.
My best code is written with the delete key.
If you were to do it recursively, how would you have done it ?Originally Posted by Prelude
>If you were to do it recursively, how would you have done it ?
I wouldn't have done it recursively, that's the point. A recursive factorial function doesn't buy you anything over a non-recursive function:
It's a silly example that displays exactly none of the benefits of recursion and all of the problems.Code:int factorial ( int n ) { int f = n != 0 ? n : 1; while ( --n > 1 ) f *= n; return f; }
My best code is written with the delete key.
>>A recursive factorial function doesn't buy you anything over a non-recursive function.
Sometimes it buy.
1.It makes the code short n sweet.
2.Sometimes its easy to find recursive than iterative soln for a novice like me.
Of course recursive soln have lots of overhead but who cares when it is short program .
Long time no C. I need to learn the language again.
Help a man when he is in trouble and he will remember you when he is in trouble again.
You learn in life when you lose.
Complex problems have simple, easy to understand wrong answers.
"A ship in the harbour is safe, but that's not what ships are built
for"
You're right. It doesnt show the benefits of recursion. I wasnt thinking of compile overhead or anything like that. When I see a recursive function (i.e factorial etc) then I guess its natural for me to think along the lines of implementing it recursively. Weather this approach is desirable or not is highly dependent on the circumstances.Originally Posted by Prelude
Anyway, to complete a simple task as the one outlined I dont see the harm. Its also a simple excercise in thinking in another paradigm, which cant be all that bad.
>When I see a recursive function (i.e factorial etc) then I guess its
>natural for me to think along the lines of implementing it recursively.
True, but an elegant recursive description doesn't necessarily translate into an elegant recursive function. As a general rule, I avoid recursion unless it clearly solves a smaller version of the same problem, but also divides the problem roughly in half at each step. At least then I have a good chance of the function not being ghastly. As with any guideline, this doesn't always apply, but it fits for a lot of the algorithms work that I do.
>Anyway, to complete a simple task as the one outlined I dont see the harm.
Also true, but IMO it's akin to bubble sort. Sure, it's fine on the small problems that teachers mean it to be used for, but they neglect to mention that it's godawful slow for anything else. That's why you always see recursive solutions for the fibonacci series when those people really should know better. You said "Do it recursively", with no mention of the pitfalls. There's nothing wrong with using a suboptimal solution as long as you're aware that there are better choices and make an informed decision.
My best code is written with the delete key.