# Tips for writing proofs

When writing formal proofs in abstract and linear algebra, what kind of jargon is useful for conveying solutions effectively to others? In general, how should one go about structuring a formal proof so that it is both clear and succinct? What are some strategies for approaching problems that you will need to write formal proofs for?

-
Favour words over symbols. – Pedro Tamaroff Dec 19 '13 at 2:19
Read books written by good authors and try to emulate their style. For abstract algebra, Gallian's Contemporary Abstract Algebra is hard to beat. As the answer below states, pictures are often very helpful. Pedro's advice is wise. For a long proof, try to break it up into steps, like you would a computer program. – Stefan Smith Dec 19 '13 at 2:34

That is a mouthful of questions. There are no definitive answers, but here are some ideas:

Being clear and succinct: First, when you write your proof, make sure you define your terms, and your symbols. Don't make your readers scramble to look up terms. And if someone doesn't know what $\phi (a)$ is, how is he supposed to find out?

Of course I'm not suggesting you define things like "a group of order 15". This really is standard. If your reader doesn't know what a group is, he should read elsewhere. But I've had recent encounters with words like "unicity" (does he mean uniqueness?). What does the symbol dL/dT.L mean? Maybe it's standard somewhere, but I've never seen it. If there is any doubt, define what you mean.

Next, settle on a clear scheme for your notation. If you have two vector spaces V and W, maybe your V vectors should be {$v_1, v_2, ... v_n$} and use w's for the W space. Why use a's and b's? Yet some people do. Worse, they change the notation in midstream -- a guaranteed way to confuse people. Then there are the writers who reuse symbols and assign them different meanings later in the proof.

I would add that personally I am not a fan a Greek letters, if only because they are a pain to type; but they can be hard to read also. However, if you have an "A" and "a" that are related and want to introduce an $"\alpha"$ that is also connected, that makes sense.

Once you've figured out your proof, think of writing it as if you were trying to explain it to a bright high school algebra student. Write down each step and at least on the first draft don't leave out any steps. Make sure you explain properly how you get from each step to the next.

As with defining your terms, this requires some judgement. If you write "x + 3 = 6 so that x = 3" you don't have to explain. If you write "a group of order 15 must have subgroups of order 5 and 3" whether you explain depends on who your audience will be. If it is a conference of group theorists, you can skip the explanation. If it is a 1st course in group theory, you probably should include it.

Begin by erring on the side of including more rather than less explanation. Note the word "begin". Clear, succinct proofs to not spontaneously spring into life. They are usually the result of several careful, attentive drafts. If I'm writing seriously I usually plan on 4 drafts. This is true even for material that has nothing to do with math, which people manage to misunderstand anyway.

Do not skimp on drafts, but put each one away for awhile before starting on the next. Then reread what you did with a newly critical eye. What would your supposed high school student think?

Finally, if you have a lot of explanation that is impeding the flow of the proof, move some of it to footnotes. That way people can follow your argument without getting tangled up in the details. If they really want the details, they'll read the notes.

How to approach: Many books have been written on this endless subject. I can't write a book but here are some ideas:

A. Make sure you understand what is being asked. Do you understand the definitions? How are you going to prove something about independent vectors if you don't know what "independent" means.

B. Start with some simple examples. You have a problem in $R^n$? Can you solve it for $R^2$? Many such solutions do not really depend on the 2 and will generalize immediately. You have a problem about groups? Can you solve it for a cyclic group? For an Abelian group? For $S_3$?

Someone once accused me of thinking all matrices are diagonal. I don't really think that, but if I can solve it for a diagonal matrix, maybe I can solve it for a diagonalizable matrix.

Once you see how things are working in a simple case, you may get some insight into what is going on. Or maybe you can piggyback on your special case -- show that the difference between that and the general case doesn't affect things much.

And starting with a special case is time-honored. Many important papers have proved only a special case of what is really desired.

C. Develop a big bag of techniques. There are things that are used over and over, homomorphisms, isomorphisms, linear operators, basis, adjoint etc. etc. Start with the common techniques. Work a lot of problems involving these techniques. Someone said that if you have a hammer all problems look like a nail --well not everything can be solved with an isomorphism (I wish it could). How is that for a mixed metaphor? Avoid them in your papers.

The more problems you work, the more techniques you will know. You can never know too many.

There is no short cut to this.

-

This is a quote from a book called Visual Complex Analysis by Needham

"The basic philosophy of this book is that while it often takes more imagination and effort to find a picture than to do a calculation, the picture will always reward you by bringing you nearer to the Truth"

I find that a picture whenever possible always helps and never hinders.

-
+1. Never is a bit strong, but pretty nearly true. – Eric Stucky Dec 24 '13 at 6:28

You might find this useful: Halmos on Writing Math

-

In general, a good proof is one that the intended audience can verify with complete certainty. In other words they should not have to ask any questions to be fully convinced of its correctness. Personally, I would also prefer a proof that is well-structured and does not need one to maintain in the head the current context (analogous to the scope of a statement in a computer program) but explicitly displays its structure, because it prevents mistakes and makes verification easy.

-