Guidelines for Homework Style

Homeworks for CS 273 should 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 will also award bonus points for exceptionally good style.

1. Your homework should be comprehensible. Solutions and proofs should be like good programs: clear, well-organized and complete.
2. Your solutions should also be concise. Most students write solutions which are too short, but a few of you write solutions that are too wordy.
3. You must explain the steps in your construction or proof. Except in the most simple, mechanical exercises, it is not sufficient to give a bare sequence of equations. Glue them together with phrases that explain why each assertion is true and that relate each step to previous steps in the proof.
4. Your explanations must be in literate English, e.g. complete sentences, appropriate punctuation.
5. 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.
6. If a problem calls for an answer, program, formula, etc, you must include a convincing argument that your answer is correct. (The instructions for each problem will indicate whether we require a formal proof or merely an informal explanation.)
7. Explain the high-level structure of your solution. For example, if you are doing a proof by contradiction, say so at the start. If your proof has two main parts (e.g. base and inductive steps), label them clearly.
8. If you are constructing a complex machine or grammar, tell us the intuition behind your construction. Diagrams or concrete examples are sometimes helpful. Such explanations aren't substitutes for a formal proof, but they make the proof easier to understand and help us give you partial credit if you were on the right track but made mistakes working out the details.
9. Diagrams are often useful for helping us understand what you meant, especially when your mathematical notation is buggy.
10. 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.
11. 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)? You may have to handle these cases separately, if you can't easily adapt your main proof to cover them.
12. As the term progresses, the model solutions distributed for each homework will give you a better idea of the expected style and amount of detail required.