Lecture 10

People write buggy code. There are a number of possible approaches to deal with this, including: (1) Have the program self-check (eg., through the use of \texttt{assert} statements. (2) Hire smarter people (not very practical). (3) Software engineering methodologies (code reuse, code reviews, etc.) (does it really work?) (4) program testing (does it engender much confidence?) (5) program verification (feasible on real examples?). Program checking is along the lines of (1). The notion is due to Manuel Blum.

Let pi be the computational problem we want to solve and let P a program which supposedly solves pi. P is CORRECT if for all instances I, P(I)=pi(I). P is BUGGY on I if P(I)!=pi(I). P is BUGGY if there is some I s.t. P(I)!=pi(I). Algorithm C, which interacts with program P, is a checker for (P, pi) if: (1) if P is correct, then, for every I, C says P is CORRECT on I. (2) if P is buggy on I, then, with enormous probability, C says P is BUGGY on I.

Next we made a big parenthesis and described the Strassen method for matrix multiplication. The main point was that, in an effort to be efficient, our code might get complex, and therefore (perhaps) buggy. But the method itself is interesting; using it, we multiply n-by-n matricies in O(n^{\lg_2 7}) time.

Next we described a checker for matrix multiplication. Let R be the machine's set of real numbers, and let R[0,1] be the ones of these in [0,1]. Program P, given n-by-n matrices A, B of points in R[0,1], is supposed to return their product (we'll assume it is supposed to be the numerically-accurate product, using whatever precision is necessary to represent each element of the product). Suppose P returns S. To check S=AB, checker C generates a random n-vector r of points in R[0,1]. It computes n-vectors Sr and A(Br). If they are the same, output CORRECT; if they are different, output BUGGY. Clearly if P is correct, C always outputs CORRECT. We will show next time that if P is buggy on I, C almost always outputs BUGGY.