ClassW04ApproxAlgs/ProofsGroupAdvice

Top | ClassW04ApproxAlgs | recent changes | Preferences

Difference (from prior major revision) (no other diffs)

Added: 112a113
* [Combinatorial Problems and Exercises] by Lovasz.

Neal's advice

If you want to prove X:

0. Make sure X is precisely stated. That is, know what you are trying to prove.

1. First, find out for yourself whether X is true or not. Hopefully, you can find an argument that makes you sure X is true. In this part, you don't know the truth; you are searching for it. The kind of reasoning you need here is domain dependent. Try making precise conjectures and verifying them or proving them false. Make sure to consider that X might be false. Switch back and forth between trying to establish that X is true and trying to establish X is false. Learn to distinguish between plausible arguments and certain arguments.

2. Once you have convinced yourself that X is true, figure out how to write your reasoning down so that the intended readers of the proof will be able to understand what your argument is. In this part, you are searching for a clear way to explain your reasoning, so that the other person will be able to see why X is true for themselves.

A proof is a convincing argument. Proof is possible in domains like math and computer science where we deal with simple systems, for which we believe we can state what we mean in a way that others can understand precisely. A good test of whether a statement is precise is "is it clear that this statement is either true or false?" (even if you don't know which, it should be clear the statement is either true or false).

In computer science, we seldom give completely detailed formal proofs (such as one learns in high school geometry -- proofs based on axioms and so on). That is usually unnecessary because the objects that we study (graphs, Turing machines, running times) are usually simple and concrete enough that we don't need axioms to be sure we are all thinking about the same concepts.

Although are proofs are not axiomized, they still need to be rigorous, but what "rigorous" means is less well defined. Roughly, each statement you make should follow clearly from the assumptions of the problem and the statements that you have already proven. "Clearly" is a relative term, depending heavily on the reader. What is clear to an experienced reader will not be clear to an inexperienced one. So, the right level of detail to give depends upon the intended reader.

In explaining your reasoning, use precision and modularity appropriately. Use mathematical notation if necessary for precision and to avoid ambiguity. Introduce definitions of new terms if necessary to capture the relevant underlying concepts. If you define a term, give a precise definition. Make sure the statements of your lemmas are precise, so that any imprecision or ambiguity within the proof of the lemma is contained. Even if the reader doesn't understand the proof of the lemma, he or she should be able to understand precisely what the lemma is claiming. Indeed, if the reader skips the proof of the lemma, this should not interfere with being able to verify the rest of the argument (where the lemma is used).

Break your proof into smaller pieces, if necessary, to manage complexity, just as you would use subroutines when programming. Try to structure your proof so that the reader knows exactly what knowledge he or she needs to carry forward at each point in the proof. Try to keep to a minimum what the reader needs to carry forward as they read.

For example, suppose you are proving that problem A can be solved in polynomial time. Suppose the high level structure of a proof is

1. Problem A reduces in polynomial time to problem B.
2. Problem B has a polynomial time algorithm.
3. Therefore problem A has a polynomial time algorithm.
In this case, the proof will have two main components: showing part 1 and showing part 2. Typically, the proofs of these two parts are independent. That is, once one verifies the proof of part 1, one can forget the details of that proof when verifying the details of the proof of part 2. This is what we mean by modularity. Modularity reduces the amount of information the reader has to carry forward, and it reduces the potential interactions between the various parts of the proof that the reader needs to be careful about. This makes it easier for the reader to understand and verify your proof.

Before you practice writing proofs on paper, practice giving proofs to friends, where interaction is possible. That is, once you believe you understand why X is true, see if you can explain it to someone. This is usually easier than writing a proof, because your friend can ask for clarification. Interaction helps achieve clarity. This kind of practice will develop the skills you need both for thinking on your feet and for explaining clearly.

Once you have a proof, you might want to ask "Is there another proof?" Maybe you can find a simpler proof, one that is easier to explain. Maybe the proof you found has unnecessary parts. (You found a long path from A to B. Now that you know one way to get from A to B, spend some time to find if there is a clearer way.)

At a minimum, a proof should be verifiable. That is, the reader should be able to leave knowing that what you claimed is in fact true, even if they have no idea why it is true, or how you found the proof. A higher standard is that the proof should be intuitive, meaning that the high-level ideas should be clear, the techniques that one might adapt to use in other problems should be clear, and the reader should have some sense for how you found the proof.


References:

Your advice or comments here...


Top | ClassW04ApproxAlgs | recent changes | Preferences
This page is read-only | View other revisions
Last edited January 30, 2004 11:11 pm by NealYoung (diff)
Search: