2 ms·
I do agree with the quoted statement. I have a lot of experience with machine-verified proofs (in a language called Coq). Even though Coq guarantees that an acc
by chrismonsanto 13y ago
I do agree with the quoted statement. I have a lot of experience with machine-verified proofs (in a language called Coq). Even though Coq guarantees that an accepted proof is correct, you still can't necessarily trust it, because your formal model of the program may be not accurate enough, or your statement of correctness is improperly stated.
In this case, it seems like their proof was correct with respect to their model, but their model did not match up with reality. No amount of formalization will ever be able to solve this problem completely. I think the role of testing in this context is to make sure your formalization of the problem says what you meant to say about the world that you meant to refer to. Input/output examples (aka, tests) are a great way of convincing yourself of this.
- skrebbel 13y agoThis hinges on the definition of "program". The OP did not say "algorithm", which is often assumed to be something on paper rather than a piece of working code in $LANGUAGE. I believe that nearly anyone will assume that a "program" is something tangible, something that a computer can run. So, the OP did not prove the program correct, but he did prove the underlying algorithm correct.