## Homework Style

For full credit, homeworks for CS 173 must meet the following style guidelines. They are intended to help you develop good mathematical style and to allow us to grade homeworks in a sensible manner. We will deduct points for excessively bad style, especially when we have trouble understanding your solution. We may also award bonus points for exceptionally good mathematical presentation.

First, and most importantly, remember that you are writing to another human, much like yourself. You aren't writing for a computer or a Vulcan. You aren't writing for a God-like teacher who can figure out what you must have meant. Therefore:

1. Your homework should be comprehensible. Solutions and proofs should be like good programs: clear, well-organized and complete. They should be in literate English and not excessively wordy.
2. Except for the most simple, mechanical exercises, it is not sufficient to give a bare answer or a bare sequence of equations. You must explain why your answer is correct and comment key steps in your proofs. Use connector words to make the flow of ideas clear.
3. If your solution is complex, first briefly sketch the idea behind what you are doing.
4. Do include diagrams and/or concrete examples. They cannot substitute for a formal proof but they help the reader understand what you are trying to do.

More specific style issues include:

1. In a direct proof, the steps must be in logical order: start with the given information and end with the desired conclusion. Do not, for example, start with the desired equality and manipulate both sides until they are equal to one another.
2. When using a proof outline that is not direct proof, start with a lead sentence that introduces that proof method, e.g. "Suppose not." for a proof by contradiction.
3. Key subsections of proofs should be clearly labelled, e.g. the base and inductive step of an induction proof, the various cases of a proof by cases.
4. Algorithms should be described in high-level pseudo-code. High-level pseudo-code is formatted like code, but the steps are written in mathematical English. If the algorithm is at all complex, include comments that summarize the main steps or main ideas. It is unacceptable to submit something that looks like C or Java code, where the main ideas are buried in lots of low-level coding details.
5. Introduce new variables politely, using phrases like "for all" or "there exists" or "let k be an arbitrary integer". Give their types (e.g. integer, real number, graph edge) if it isn't obvious from the context.
6. Make sure your proof or solution is correct for ``boundary'' conditions. For example, what if the set A is empty? Or what if x = 0 (so you don't want to divide by x)? Handle these cases separately if you can't easily fit them into your main proof.

See the textbook and/or posted model solutions for examples of the expected style and amount of detail required.