Could I ask for physical analogies or metaphors for recursion?

Question

I am suddenly in a recursive language class (sml) and recursion is not yet physically sensible for me. I\'m thinking about the way a floor of square tiles is sometimes a mo

Answer 1

I love this question and couldn't resist to add an answer...

Recursion is the russian doll of programming. The first example that come to my mind is closer to an example of mutual recursion :

Mutual recursion everyday example

Mutual recursion is a particular case of recursion (but sometimes it's easier to understand from a particular case than from a generic one) when we have two function A and B defined like A calls B and B calls A. You can experiment this very easily using a webcam (it also works with 2 mirrors):

1. display the webcam output on your screen with VLC, or any software that can do it.
2. Point your webcam to the screen.
3. The screen will progressively display an infinite "vortex" of screen.

What happens ?

• The webcam (A) capture the screen (B)
• The screen display the image captured by the webcam (the screen itself).
• The webcam capture the screen with a screen displayed on it.
• The screen display that image (now there are two screens displayed)
• And so on.

You finally end up with such an image (yes, my webcam is total crap):

"Simple" recursion is more or less the same except that there is only one actor (function) that calls itself (A calls A)

"Simple" Recursion

That's more or less the same answer as @WillNess but with a little code and some interactivity (using the js snippets of SO)

Let's say you are a very motivated gold-miner looking for gold, with a very tiny mine, so tiny that you can only look for gold vertically. And so you dig, and you check for gold. If you find some, you don't have to dig anymore, just take the gold and go. But if you don't, that means you have to dig deeper. So there are only two things that can stop you:

1. Finding some gold nugget.
2. The Earth's boiling kernel of melted iron.

So if you want to write this programmatically -using recursion-, that could be something like this :

// This function only generates a probability of 1/10
function checkForGold() {
  let rnd = Math.round(Math.random() * 10);
  return rnd === 1;
}

function digUntilYouFind() {
  if (checkForGold()) {
    return 1; // he found something, no need to dig deeper
  }
  // gold not found, digging deeper
  return digUntilYouFind();
}

let gold = digUntilYouFind();
console.log(`${gold} nugget found`);

Or with a little more interactivity :

// This function only generates a probability of 1/10
function checkForGold() {
  console.log("checking...");
  let rnd = Math.round(Math.random() * 10);
  return rnd === 1;
}

function digUntilYouFind() {
  if (checkForGold()) {
    console.log("OMG, I found something !")
    return 1;
  }
  try {
    console.log("digging...");
    return digUntilYouFind();
  } finally {
    console.log("climbing back...");
  }
}

let gold = digUntilYouFind();
console.log(`${gold} nugget found`);

If we don't find some gold, the digUntilYouFind function calls itself. When the miner "climbs back" from his mine it's actually the deepest child call to the function returning the gold nugget through all its parents (the call stack) until the value can be assigned to the gold variable.

Here the probability is high enough to avoid the miner to dig to the earth kernel. The earth kernel is to the miner what the stack size is to a program. When the miner comes to the kernel he dies in terrible pain, when the program exceed the stack size (causes a stack overflow), it crashes.

There are optimization that can be made by the compiler/interpreter to allow infinite level of recursion like tail-call optimization.

Answer 2

This is odd, and not quite a physical example except insofar as dance-movement is physical. It occurred to me the other morning. I call it "Written in Latin, solved in Hebrew." Huh? Surely you are saying "Huh?"

By it I mean that encoding a recursion is usually done left-to-right, in the Latin alphabet style: "Def fac(n) = n*(fac(n-1))." The movement style is "outermost case to base case."

But (please check me on this) at least in this simple case, it seems the easiest way to evaluate it is right-to-left, in the Hebrew alphabet style: Start from the base case and move outward to the outermost case:

                                                   (fac(0) = 1)
                                      (fac(1) = 1)*(fac(0) = 1)
                             (fac(2))*(fac(1) = 1)*(fac(0) = 1)
       (fac(n)*(fac(n-1)*...*(fac(2))*(fac(1) = 1)*(fac(0) = 1)
(*  Easier order to calculate <<<<<<<<<<< is leftwards, 
    base outwards to outermost case;
    more difficult order to calculate >>>>>> is rightwards, 
    outermost case to base  *)

Then you do not have to suspend items on the left while awaiting the results of calculations further right. "Dance Leftwards" instead of "Dance rightwards"?

Answer 3

I came across this piece from Edsger W. Dijkstra; he tells how his child grabbed recursions:

A few years later a five-year old son would show me how smoothly the idea of recursion comes to the unspoilt mind. Walking with me in the middle of town he suddenly remarked to me, Daddy, not every boat has a lifeboat, has it? I said How come? Well, the lifeboat could have a smaller lifeboat, but then that would be without one.

Answer 4

Take fractals as being recursive: the same pattern get applied each time, yet each figure differs from another.

As natural phenomena with fractal features, Wikipedia presents:

• Moutain ranges
• Frost crystals
• DNA
• and, even, proteins.

Answer 5

Imagine you're a real life magician, and can make a copy of yourself. You create your double a step closer to the goal and give him (or her) the same orders as you were given.

Your double does the same to his copy. He's a magician too, you see.

When the final copy finds itself created at the goal, it has nowhere more to go, so it reports back to its creator. Which does the same.

Eventually, you get your answer back – without having moved an inch – and can now create the final result from it, easily. You get to pretend not knowing about all those doubles doing the actual hard work for you. "Hmm," you're saying to yourself, "what if I were one step closer to the goal and already knew the result? Wouldn't it be easy to find the final answer then ?" ^*

Of course, if you were a double, you'd have to report your findings to your creator.

More here.

(also, I think I saw this "doubles" creation chain event here, though I'm not entirely sure).

---

^* and that is the essence of the recursion method of problem solving.

How do I know my procedure is right? If my simple little combination step produces a valid solution, under assumption it produced the correct solution for the smaller case, all I need is to make sure it works for the smallest case – the base case – and then by induction the validity is proven!

Another possibility is divide-and-conquer, where we split our problem in two halves, so will get to the base case much much faster. As long as the combination step is simple (and preserves validity of solution of course), it works. In our magician metaphor, I get to create two copies of myself, and combine their two answers into one when they are finished. Each of them creates two copies of themselves as well, so this creates a branching tree of magicians, instead of a simple line as before.

---

A good example is the Sierpinski triangle which is a figure that is built from three quarter-sized Sierpinski triangles simply, by stacking them up at their corners.

Each of the three component triangles is built according to the same recipe.

Although it doesn't have the base case, and so the recursion is unbounded (bottomless; infinite), any finite representation of S.T. will presumably draw just a dot in place of the S.T. which is too small (serving as the base case, stopping the recursion).

There's a nice picture of it in the linked Wikipedia article.

Recursively drawing an S.T. without the size limit will never draw anything on screen! For mathematicians recursion may be great, engineers though should be more cautious about it. :)

Switching to corecursion ⁄ iteration (see the linked answer for that), we would first draw the outlines, and the interiors after that; so even without the size limit the picture would appear pretty quickly. The program would then be busy without any noticeable effect, but that's better than the empty screen.