Live data from Hacker News

Thinking About Recursion

solipsys.co.uk

11–20 of 42 posts

Re: Thinking About Recursion

#12
post #10

One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…

[deleted]

Re: Thinking About Recursion

#13

I always thought recursion was very elegant, but until now I was using it to scan through folders on the file-system and that was about it. Then I had an interesting problem at work where recursion seemed the most elegant solution ... but I quickly encountered errors that were not caught in a try catch block and made the program fail silently. I'll admit my ignorance, but I thought a stackoverflow was a "feature" of…

You really need language support to make recursion the best practical solution for most problems. However, even when working in "normal" languages like C#, I find that recursion has utility in designing solutions--it is often easiest to find a provably-correct solution for an inherently recursive problem by actually designing a recursive algorithm; you merely then have to perform some compiler work yourself to transf…

In some cases in C# you can write a tail-recursive function and then have Resharper rewrite it into a loop for you.

Re: Thinking About Recursion

#16
This was how I was "taught" recursion, with (Lucas) Towers of Hanoi. Ugh! I still remember the mostly-filled in function with 2(?) recursive calls placed, for us to fill in the arguments. How the heck would that ever work? was all I could think. I don't think a single person in the class had any idea of progress until the teacher, kinda exasperated, just told us. And we still didn't get it, of course. I get it now, but only from a more task-oriented mindset, not Java Mad Libs.

The only recursion that still bothers me is Clownsort / Stooge sort [0]. That such an algorithm would work is still not my gut feeling.

[0] https://en.wikipedia.org/wiki/Stooge_sort

Re: Thinking About Recursion

#17
post #2

I like thinking about variables as boxes with labels. Hadn’t heard that before, but seems like a simple way to teach people. I skimmed the description of recursion. Seemed a bit long for my taste. I was taught how to write a recursive function like this: “Write the function signature, the docstring, and the base case. Then assume the function already works, and use it to implement the rest of the code”

I do a similar thing but with functions: running functions are boxes with labels, function definitions are blueprints of boxes. I use it in videos [1] to explain recursion.

1. https://youtu.be/vLhHyGTkjCs

Re: Thinking About Recursion

#19
post #10

One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…

Working a problem from bottom-up flushes out a lot of the incidental information, making the problem much easier to comprehend. By using the goblin analogy you're focused on the last call, and working back from there.

The Refactoring people knew this, and the Mikado method is essentially a way to find the 'bottom' when all you can see is the top of the rabbit hole, so you can use these other skills.

Post reply on HN