A mathematical proof can be the size of a novella. For example, Andrew Wiles’s published his famous proof of Fermat’s Last Theorem in two journal articles covering 129 pages. But proofs in introductory textbooks like Rosen often contain just a few sentences. It might seem obvious that these proofs are short because they’re easy. But that’s not exactly right. Last week, I wrote a moderately long post covering an “easy” proof about how the div operator behaves when the first argument is negative. Why was it so much longer than the version in the solution guide?
Assumptions of Prior Knowledge
The goal of a proof is to convince your reader that a mathematical statement is true. To do that effectively, you have to make some assumptions about what prior knowledge the reader brings to the proof. Which assumptions you make can significantly change the length of the proof, since they determine how you describe each mathematical fact you use. You could use a fact in several ways:
- Use it without pointing it out at all, if you expect the reader to find it obvious.
- Mention it in passing, making it clear that you’re using it, but not explaining what it means.
- Explain what you’re doing without citing a specific source.
- Cite a primary or secondary source, to allow the reader to look up further details.
- Cite a source and provide a summary of what the source says.
- Prove a theorem before you use it.
Proofs in introductory textbooks generally use #4 for facts covered in other parts of the textbook. For example, a proof step might say, “By Theorem 3, we can…” or “We can use Theorem 2 from Chapter 5 to….” When the textbook author needs a fact from another mathematical discipline, they might use #1 or #2 for basic topics, and #3 for more specialized topics that the reader might remember only vaguely.
Here are some examples of how I used each of these options in the div proof:
- Although I tried to explain every nontrivial step in my proof, I didn’t point out the most basic algebraic manipulations in Step 4, the main proof step.
- At the end of the Solution Guide version of the proof, I mentioned that proving a proposition and its inverse is the same as proving an “if and only if” version of the proposition. But I didn’t explain why that is true (e.g., by showing truth table equivalence).
- I mentioned and used several properties of the floor function, but didn’t provide any references.
- I stated three relationships between div and floor in equation form, and provided a reference to Rosen, but didn’t go into any more detail.
- In Step 2, the brainstorming step, I went into moderate detail about how the div operator works, since understanding that operator is key to understanding the proof. I also cited the Rosen definition for the Division Algorithm, explained what it means, explained how it relates to div, and provided examples of how it works. But I didn’t prove anything in this step.
- Although I proved several related theorems on my own while going through the exercises in Rosen, I didn’t reproduce those proofs in last week’s post. Two proofs of the main div theorem was plenty for one article.
One Does Not Simply Read a Proof
As anyone who has studied math or science textbooks knows, they require different reading techniques than other books. In How to Read a Math Textbook, I quoted a writer who compared the process to digging something out of the ground. If you want to encourage a DIY mindset in your readers, it may not be worth explaining things too carefully. Just make sure your proof is correct and precise, and let the reader dig out the rest.
I can understand this point of view. If you read through the div proof at regular blog post speed, you might not follow it, even though I spell out the math in extreme detail. There are just too many symbols. So if readers have to read through the proof line by line anyway, what’s the benefit of adding more detail? Again, it comes down to the audience the proof is written for. If you’re writing it for an instructor, then more detail demonstrates that you understand the proof. If you’re writing it for yourself, then writing more detail can improve your understanding of the proof, and ensure that you know how each step works. But if you’re writing a textbook or an answer key, it may be pedagogically best to let the reader fill in some gaps.
Time and Space
The most obvious reason a proof is short is time and space constraints. Textbook authors don’t have unlimited pages. Students don’t have unlimited time to finish assignments. Readers of Wikipedia don’t have unlimited time to read math articles, even though there’s no article size limit and editors may want to keep writing. So the proof eventually must end.
If you’re studying math on your own, most of these constraints disappear, and it’s mainly a question of how long to work on a problem before looking at the answer. When considering that question, the principles that apply to programming problem practice also apply to math proof practice: how many problems you want to cover, the benefits of struggling with a problem, how hard the problem is, whether you have the right background, and whether you’re still getting something out of the process. But although you have to stop eventually, for the purpose of learning proofs, I think longer is usually better.
I’m writing about discrete math and competitive programming this year. For an introduction, see A Project for 2019. To read the whole series, see my Discrete Math category page.
(Image credit: Insomnia Cured Here)