This preview shows pages 1–2. Sign up to view the full content.
Handout #31
CS103A
Feb. 11, 2008
Robert Plummer
Proving "Real" Theorems
We have just spent weeks learning about firstorder logic and how to do both formal and informal
proofs in FOL.
For the most part, the proofs we have done pertained to formal logic, e.g., we
proved things about P, Q, R, etc.
We occasionally did a proof where we were interested in the
actual meaning of the premises and the conclusion.
Now, we turn our attention to mathematical proofs.
Our goal is to use the foundations that we
have laid in formal logic to help us derive solid proofs of meaningful statements.
We will begin
by doing “semiformal” proofs in this context where we provide detailed statement and reason
charts. We call such proofs semiformal because they will not be as rigorous (and capable of
mechanical checking) as the ones we did in Fitch.
But our semiformal proofs will leave out no
steps.
As we proceed, we will begin to work on the skills required to do informal proofs.
It takes
practice learning what is appropriate to leave out in an informal mathematical proof.
Why is Proof Important?
Most students are introduced to the concept of mathematical proof in highschool geometry.
There, students learn that you have to do a proof about geometric properties because:
1) Observation cannot prove because our eyes can deceive us.
For example, these
horizontal lines are the same length):
2) Measurement cannot prove because the certainty of the conclusion we arrive at is
dependent on the precision of the measuring instrument and care of the measurer.
3) Experiment cannot prove because the conclusions are only probable ones:
It is probable
that the dice are loaded if 10 successive 7's are thrown; it is even more probable if 20
successive 7's are thrown (
but
it's not certain).
This last example is especially relevant in computer science.
Thus far, you have validated the
correctness of the programs that you write by testing, i.e., by experimentation.
In most cases
however, it is impossible to test all relevant inputs.
So, you do enough testing to convince
yourself that the boundary cases and several cases in between are covered.
This is good enough
This preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
This is the end of the preview. Sign up
to
access the rest of the document.
This note was uploaded on 10/01/2011 for the course CS 103A taught by Professor Plummer,r during the Winter '07 term at Stanford.
 Winter '07
 Plummer,R
 Computer Science

Click to edit the document details