[Math] Proofs vs. documentation vs. "it's trivial"

post by aaq · 2019-11-03T16:50:17.428Z · LW · GW · 0 comments

Contents

No comments

In my abstract algebra and real analysis classes, my TAs say that I frequently come up with "technically right" solutions. They don't mean in the Futurama sense; "technically right" here is a little looser - I did some trick that wasn't really expected, or a bit outside of the nature of the class, in order to arrive at my proof.

This is really cool! I readily admit my ego is a bit boosted by contrasting my less obvious approach to the more studied approach of my classmates. It's good to embrace what's unique about yourself.

The problem is that the solutions I generate on a homework problem, where I have all the time in the world to putt about and generate little sub-proofs and lemmas, don't work in an exam situation. I don't write that fast. Even if I did write that fast, I don't think that fast. The things I claim aren't quite so trivial that I feel comfortable using them without proof - I'd lose points if I did.

Calling something "trivial" in math is more of a judgment call than I think people realize. The universal-accessibility option for triviality might be to hyperlink to someone else's proof of a claim, that is in roughly the same flavor as your own; that way, a reader who feels confident they could reconstruct the proof can just read over it, without hurting the flow of the text, and someone who feels less confident could slow down. Since a lot of good mathematics texts are designed to be reread to jog one's own memory from time to time, this seems like an especially good balance - after reading the proof through the first or second time for the nontrivial triviality, it probably genuinely does start to look trivial to you. You've absorbed whatever was missing that made it look nontrivial.

And that's interesting. I think that "trivial" statements are more like heuristic-checks than nontrivial ones. Do you have the requisite background knowledge to grind this proof out without breaking a sweat? Do you realize you have that knowledge - is it a "known known" for you? Maybe it's an unknown known, that happens often. But it also happens often that you genuinely have mismatched heuristics for the problems in question. They probably aren't wrong -- they're just not a good fit for right now.

Mismatched heuristic-checks are the same phenomena, I think, that causes my first-pass proofs to be called "technically correct" by my professors. These problems were probably specifically chosen to be challenging to an undergraduate, but not so challenging that they appear nontrivial to the grader, who themselves have much more experience with the field. When a proof is trivial to the grader, they can devote more mental energy to the rote work of making sure the proof-writer crossed their Ts and dotted their Is. So when you do something surprising, there really is a sense in which it's the 'wrong' approach to the situation, even if it gets the right answer.

For now, my solution is to apply some of the principles of good code documentation to my proofs. Good code documentation usually provides whatever is being documented at various levels of complexity:

• There's usually a few concrete examples of the code in use, for the programmer who's in a hurry and just needs to know what to do. (Honestly, if we're talking raw number of function lookups, this one is the one I get the most value out of.)
• There's usually a link or an embedded snippet of what the code actually is. For a function, this is a link to the definition in the database itself, preferably automatically updating with new builds. This is so that someone who wants to look into the explicit construction of the abstract thing we're talking about can do so, and is tremendously helpful in spotting bugs. This is the closest thing to what we usually think of as the "proof" part of a math proof, and it is indeed the most critical part of both, in different senses. But it's not always good for explaining what's going on.
• Finally, there's usually a short bit about what's going on in plain English, maybe some informal explanation of how to use this bit of code or what its various arguments do.

I don't mind spilling some extra ink to explain what I'm doing clearly to the reader -- if I lose points, I at least want it to be exceedingly clear what mistake I made that caused me to lose them. I still have to go back and learn the "proper" way to do things for exams, but this is a happy medium for me when it comes to my homework.

0 comments

Comments sorted by top scores.