So, here's how I approach developing an algorithm. I start with the problem statement and figure out how I would do it by hand. For your problem, you can easily sit in front of a piece of paper and solve the problem by hand -- do that and pay attention to how you're accomplishing the task.
I then solve a few simple examples by hand to verify that the algorithm makes sense. While I'm thinking about that, I look for repetitive tasks -- things that might go in a loop or subroutine. I look for nearly repetitive tasks -- things I could re-organize so that I could do those tasks with the others in a loop or a subroutine.
You can sit and think a little more: optimize this, do I really need to do that, is there a better way to do some or all of it? This part is optional, though, depending on the nature of the task and the time available to do it.
Unlike several of the responders, I hadn't seen this problem, before. Following this method, though, yielded both the iterative and the recursive solutions described by other posters in 10 to 15 minutes. Having a method to solve the problem helps you break out of the cycle of "Oh crap -- how am I going to solve this? If I don't solve this, I may flunk this class. I may not be cut-out to be a programmer. Yikes! I may not be cut-out to do anything. But I *like* to eat. Food, hmmm, I could use a cookie right now. And some cheese...".
Good luck!
In reply to Re^5: Recursion problem
by wade
in thread Recursion problem
by someone202
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |