The idea of proving programs correct has been around (and hotly debated) for roughly forty years. The irony is that some proof advocates anticipated by more than thirty years what the agile advocates are now saying:
Designing with verification in mind improves the quality of the resulting design.
To be even more specific, compare these statements:
| Design the proof, then write the code so that it meets the obligations of the proof. |
Write the test first, then write the code so that it passes the test. |
|
| —Edsger Dijkstra (paraphrased) | —Kent Beck (paraphrased) |
I’ve experienced the benefits of following both pieces of advice. Let me apply this approach to a little bit of design which I’ll then use in the Project Euler series. There’s a small amount of algebra involved, but if you don’t want to bother with that, let me request that you at least look at the last section for the punchline.
Sum thing
Consider the following sums, where i in each case ranges from 1 to n:
| Power | Sum | Expanded form | Closed form | Factored form |
|---|---|---|---|---|
| 0 | ∑ i0 | 1 + 1 + 1 + … + 1 | n1 | n |
| 1 | ∑ i1 | 1 + 2 + 3 + … + n | 1/2 n2 + 1/2 n1 | n(n+1)/2 |
| 2 | ∑ i2 | 12 + 22 + 32 + … + n2 | ? | |
| 3 | ∑ i3 | 13 + 23 + 33 + … + n3 | ? | |
Let’s assume that we need the solutions for the last two rows (and Google is down at the moment 
). Using the “designing with verification in mind” approach, we can work them out for ourselves.
Sum of squares
Noticing that ∑ i0 is a polynomial of degree 1, and ∑ i1 is a polynomial of degree 2, we might suspect that the sum of i2 is a polynomial of degree 3. If so, the problem amounts to finding the coefficients for ∑ i2 = an3 + bn2 + cn + d. Let’s assume that as the structure of the solution, and apply test cases to that assumption.
Test case 0: The sum must be zero when n is zero; a03 + b02 + c0 + d = d, therefore d must be zero. That streamlines the polynomial to ∑ i2 = an3 + bn2 + cn.
Test case 1: Adding (n+1)2 to the sum for n must be equal to the result of substituting (n+1) for n in the polynomial.
| an3 | + bn2 | + cn | + (n+1)2 | |
| = | an3 | + (b+1)n2 | + (c+2)n | + 1 |
| and | ||||
| a(n+1)3 | + b(n+1)2 | + c(n+1) | ||
| = | an3 | + (3a+b)n2 | + (3a+2b+c)n | +(a+b+c) |
These two reduced expressions can only be equal if we can satisfy the equations implied by the coefficients for n2, n1, and n0:
| n? | Coefficients | Satisfied if | ||||||
|---|---|---|---|---|---|---|---|---|
| n2 | b+1 | = | 3a+b | a | = | 1/3 | ||
| n1 | c+2 | = | 3a+2b+c | b | = | 1/2 | ||
| n0 | 1 | = | a+b+c | c | = | 1/6 | ||
So we have a solution of 1/3 n3 + 1/2 n2 + 1/6 n, which we can factor to n(n+1)(2n+1)/6.
Sum of cubes
Based on that success, we’ll pursue the coefficients for ∑ i3 = an4 + bn3 + cn2 + dn + e.
Test case 0: The sum must be zero when n is zero; a04 + b03 + c02 + d0 + e = e, therefore e must be zero, therefore ∑ i3 = an4 + bn3 + cn2 + dn.
Test case 1: Adding (n+1)2 to the sum for n must be equal to the result of substituting (n+1) for n in the polynomial.
| an4 | + bn3 | + cn2 | + dn | + (n+1)3 | |
| = | an4 | + (b+1)n3 | + (c+3)n2 | + (d+3)n | + 1 |
| and | |||||
| a(n+1)4 | + b(n+1)3 | + c(n+1)2 | + d(n+1) | ||
| = | an4 | + (4a+b)n3 | + (6a+3b+c)n2 | + (4a+3b+2c+d)n | + (a+b+c+d) |
Again, we look at the coefficients for descending powers of n:
| n? | Coefficients | Satisfied if | ||||||
|---|---|---|---|---|---|---|---|---|
| n3 | b+1 | = | 4a+b | a | = | 1/4 | ||
| n2 | c+3 | = | 6a+3b+c | b | = | 1/2 | ||
| n1 | d+3 | = | 4a+3b+2c+d | c | = | 1/4 | ||
| n0 | 1 | = | a+b+c+d | d | = | 0 | ||
So we have a solution of 1/4 n4 + 1/2 n3 + 1/4 n2, which we can factor to (n(n+1)/2)2.
The punchline
“That’s no exponential, that’s my polynomial!” But seriously, folks…
The mathematicians among us–those who haven’t died of boredom–will recognize what we’ve done as an informal (hand-waving) inductive proof.
But I hope that the programmers among us will recognize what we’ve done as test-driven development and (re)factoring. Allowing verification to drive design offers a number of benefits, including:
- The result itself is verifiable.
- Each step along the way is more obvious and involves less risk.
- The result is usually cleaner and more understandable.
Incidentally, I first encountered the term “factoring” applied to programs in Leo Brodie‘s book Thinking Forth (1984). Given my background in Mathematics, it immediately clicked with me. Brodie introduced the idea with a quotation which seems entirely contemporary, once we get past the dated terminology:
“If a module seems almost, but not quite, useful from a second place in the system, try to identify and isolate the useful subfunction. The remainder of the module might be incorporated in its original caller.”
(The quotation is from “Structured Design“, by W.P. Stevens, G.J. Myers, and L.L. Constantine, IBM Systems Journal, vol. 13, no. 2, 1974, © 1974 by International Business Machines Corporation)
As a working developer, I’m excited by the potential of these techniques and the underlying ideas. But as a card-carrying member of the Sid Dabster fan club, I’m constantly amazed at the number of ideas that were actively in play in our field thirty or forty years ago that are now regarded as new, innovative, or even radical.
Recommended reading:
- Test Driven Development: By Example (The Addison-Wesley Signature Series)
- Test Driven Development: By Example (The Addison-Wesley Signature Series)
- Selected Writings on Computing: A Personal Perspective (Texts and Monographs in Computer Science)
- On the Shape of Mathematical Arguments (Lecture Notes in Computer Science)
- Thinking Forth
