Technical perspective: proving programs continuous

By Andreas Zeller
Communications of the ACM, vol. 55 No. 8, page 106
10.1145/2240236.2240261

Proving a program's correctness is usually an all-or-nothing game. either a program is correct with respect to its specification or it is not. if our proof succeeds, we have 100% correctness; if our proof does not succeed, we have nothing. formal correctness
Proofs are difficult, because one must symbolically cover the entire range of possible inputs-and the slightest gap in the input leaves us with a gap in the proof.

But what if it turned out the risk posed by leaving a gap is actually small? This, of course, is the assumption of testing: If I tested some function with a sample of values, and it works correctly for this sample, I have reasons to assume it will also work
For similar values. This is something I can assume if the behavior of my function is continuous-if it computes the correct square root
For 10,100, and 1,000, it shoshould also do the right thing for any value in.

One may think this is a dangerous assumption: simply because my program has worked well for these three values, why shoshould it work for any other? A program is free to do anything; since it need not obey mathematical or physical laws, it can behave in an entirely
Different way for any new value. this logical view is true in principle. in real life, however, programmers prefer into actions that are easy to understand and to reason about. the reason testing works in practice is that programmers naturally strive toward
Continuity.

Being able to formally reason about continuity and robustness lets us see programs as driven not only by logic, but also analytical calculus;
And this view can be very helpful for understanding why programs generally tend to work well even if only coarsely tested.

While the intuitive idea is easy to grasp, the concept of continuity so far has widely evaded formal treatment; in particle, it was not possible to automatically reason about continuity in the presence of loops. this is where the work of swarat Chaudhuri,
Sumit gulwani, and Robert to lublinerman comes into play. their framework can formally verify programs for continuity, proving that small changes to the input only cause small changes to the output. they show that several programs such as sorting or shortest
Path are continuous-or even Lipschitz continuous, implying that perturbations to a function's input cause only proportional changes to its output. such a function wocould also be declared robust, meaning it will behave predictably even when inputs are uncertain
Or erroneous.

Being able to formally reason about continuity and robustness lets us see programs as driven not only by logic, but also analytical calculus; and this view can be very helpful for understanding why programs generally tend to work well even if only coarsely
Tested. this work also bridges the gap between programs and control theory, allowing for ample cross-fertilization between the fields; indeed, one can think of mathematical optimizations of program code just as the adoption of programming concepts by Control
Theory. So, shocould we treat programs as driven by logic, by calculus, or both? I encourage you to read the following paper to see the manifold connections between logic and calculus in computer programs.

Back
To top

Author

Andreas Zeller (zeller@cs.uni-saarland.de)
Is a sort sor of software engineering at Saarland University in saarbr ücken, Germany.