in reply to Re^3: Recursion problem
in thread Recursion problem

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^5: Recursion problem
by moritz (Cardinal) on May 25, 2008 at 08:56 UTC
    I did try to help you, didn't I? You asked why homework questions are generally frowned upon, and I explained.

    I know that many monks here share my resentment against homework questions, but are glad to help if you 1) don't want a complete solution, but rather a hint in the right direction (and if that's what you want, write it in your original node) and 2) show some effort on your own.

    Secondly, I am working on this one for a couple of days

    I do believe that, but your original question didn't show that. Here at the monastery we only judge you according to the nodes you write, and that wasn't very favorable to you.

    So I suggest we stop our meta-discussion and instead turn to your problem. What have you got so far? Don't be afraid to show non-working code.

Re^5: Recursion problem
by Anonymous Monk on May 25, 2008 at 08:56 UTC
    Where are you stuck? Saying "here's a problem, i'm stuck" doesn't show what you tried ... its hard to believe your teacher assigned homework you could never hope to solve on your own.
Re^5: Recursion problem
by GrandFather (Saint) on May 25, 2008 at 21:58 UTC

    If you have been working on this for some time you have some code which doesn't work. Show us that and ask for help with your code.

    If you show that you have made some effort and are willing to learn we are generally keen to help. If you simply ask for a solution to what looks like a homework problem then you get exactly the help you have received.


    Perl is environmentally friendly - it saves trees
Re^5: Recursion problem
by wade (Pilgrim) on May 27, 2008 at 20:38 UTC

    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!

    --
    Wade