## Induction through Failure

May 25, 2011 2 Comments

I was inspired by a recent post from Ben Blum-Smith about induction to talk about an approach to induction I learned from Al Cuoco. I don’t know its origins, but it really does a nice job of dealing with the issue Ben brings up: you assume you’re right then prove it. But if you’re already right, why prove it?

Our curriculum (CME Project Precalculus Investigation 4A, for those playing at home) ties induction to the process of finding closed-form rules to match recursive definitions, such as this one:

What is ? All the formula says is that , so that’s no good… except that it is, since now you do the same thing to , eventually working your way back to the “base case”. This actually works out pretty nicely:

But how many fives? Why is chasing it all the way back to a good idea? What would change with ? with ? This works to find closed-form rules for recursions surprisingly often.

Another way to find is to count off outputs: until you reach 23. More likely, you’ll figure out a pattern to the outputs before you get there… 3, 8, 13, 18…

So now you’ve got these two rules:

If I want to prove these two rules will always agree (whenever *f* is defined, anyway) it’s time for induction. *Before that*, we really want to be sure the rules agree. This is where technology comes in: using Excel or the TI-Nspire or several other tools, these functions can be entered then compared. (For the Nspire, see page 3 of this document for an example.) Now use the technology to compare and … and … and

No matter what piece of technology you use, *at some point* it is going to stop saying that these two functions agree. (On Nspire hardware, this happens somewhere around 100, but depends on the device’s memory.) Say for example that the technology agrees that but is undefined. How could you show that anyway?

By doing this, the “induction step” process is one that actually happens with a numeric value. So let’s work this one out… evaluating fails, but we know from its definition that

Oh and we also know that , because the functions agreed up to that point. So:

The induction step happens naturally, based on the failure of the technology, and based on a numeric example. (Now, try to show that …)

The steps taken above also evolve quickly into a general argument for simply by using instead of 106, and noting that 105 should be .

And, boom goes the dynamite.

I feel this method does a nice job of dealing with the “proving what you know to be true” issue that surrounds induction. This method can also help with some of the issues around base cases, because it encourages the checking of several cases before trying to complete an inductive proof. Lastly, the extension from the numeric calculation of to the algebraic calculation of lines up well with one of Common Core’s mathematical practices, “Look for and express regularity in repeated reasoning“. After all, that’s what induction is all about…