Help grasping recursion algorithms
I'm having a really hard time understanding recursion well enough to write any algorithms beyond the absolute basics. Not only are iterative forms a lot more intuitive and easy for me to write, but most of the time they seem to have a lot shorter and simpler code... so I'm definitely not understanding how to write recursive algorithms well at all.
Any help/resources? I think the problem is that I'm missing the middle steps between the basic level of recursion that I feel comfortable with and the actual scenarios (e.g. Project Euler problems) that I want to apply them to.
8 comments · 81% upvoted · other discussions
Whether recursion is easier really depends. It also depends on the language, but I'm going to stick with Python for now.
I'll try not to bore you with silly recursive mathematics like fibonacci and factorial. Those are trivial and infrequent.
I've also assumed a fair bit more knowledge than I should've; if you're stuck on any of what I've said just ask. The point isn't the code per se, though.
Say you were travelling around a filesystem and listing all the files. If you were to define this iteratively you'd find quite a few problems.
WARNING: This is not good code. Use os.walk. This is purely example material. Also there are infinite loops in here.
For the placeholder, you might be tempted to do:
but you need to remember to start the loop again, so put everything in a "while":
Also you need to break out of a directory once you've finished it. Now we have to store a list of what directories we've been in:
But.. ah! You need to store what position in the loop you're in because you reset from the top each time when you go back up the loop:
See how problematic this is? Now try adding proper fallback to that ;P.
Let's do it recursively:
That's it. State is handled for free. That is the true advantage of recursive algorithms.
This happens in many cases -- you want to go down a path and return to the original state.
Finally, it's worth noting that Python programs aren't traditionally recursive. The majority of my code is non-recursive, it's only when it's easier to express recursively that I go back to recursion. That is fine. If you only like imperative stuff it won't hurt too badly while you're learning.
chasecaleb [OP] 1 points · Aug 2013
Wow, that's an amazing example. I'm missing a few details of exactly how it works, but I can follow the overall idea easily enough, and like you said it isn't the code itself that's the point. Good job explaining.
So are you saying when you're writing code (with Python), you more or less go with iteration by default, and only switch to recursion on the occasion when iteration turns into a big mess like the above example?
Veedrac 2 points · Aug 2013
Yup.
A lot of languages, Python included, don't like too much recursion. If you know about the stack, it's that thing:
An iterative "algorithm" would continue forever without problems.
Also Python is slowish at function calls, so something like factorial is really quite bad done recursively in Python.
Finally, but most importantly, iteration is much easier when you do want to store state, which is most of the time, or you're not changing and restoring state, which is most of the time.
Some languages like Haskell design their language around recursion, so to add 1 to every item in a list you in effect do:
(but they do it much more neatly). Python isn't made for this, so I just don't bother.