**How
to write your HW **(adapted
from here: http://www.cs.uiuc.edu/class/sp07/cs473g/policies.html)

In short, make it easy for the
grader to figure out what you mean. If your solutions are difficult to read or
understand, the grader will be less sympathetic to your mistakes.

**Write clear, concise, legible, and sensible solutions.**In your exposition, your goal is always to be as clear as possible. If you are unable to make something clear, it is most likely because you do not understand thoroughly enough what you are trying to say. When in doubt about omitting steps in a logical progression of thought because they seem obvious to you at the time, keep in mind that you should make things as easy as possible for the reader/grader to follow your work. I.e., don’t make the reader/grader have to work hard to earn your points for you, try to take them on a pleasant (and interesting) stroll from the problem to the solution.**Don't babble!**If you don't know the answer, don't do a brain dump, hoping to get partial credit for including a few key words. That won't work in this class. A crucial part of mastering any new material is learning to recognize when you don't know something. Long-winded, irrelevant, and/or nonsense discussion is very frustrating for graders to read and will often include incorrect statements that necessitate grading penalties.**Be honest and write your solutions with integrity**. A clear and concise incorrect solution, which includes an explanation of why it is incorrect, is also worth more than one where you haven’t admitted that it’s wrong. (Because when you know that you’re wrong, it means you’re closer to getting the answer than if you think that your wrong answer is correct.) Another acceptable answer is that you don’t know how to solve the problem, with an explanation that concisely gets to the heart of where your troubles lie. Such answers will be graded more charitably than the kind where you write incoherently for some time, without conceding that you don’t have the right answer.**Give a top-down, breadth-first description.**Carefully describe the high-level ideas behind your solution before going into details. The reader should understand your approach almost immediately. An incomplete solution that includes all the main ideas but omits some details is worth far more than a complete, correct, detailed, but opaque solution.**Use pseudocode or outline format to describe your algorithms. Do**Your description should be human-readable. See the textbook for examples of the type of presentation we want. Ideally, your description should allow a competent programmer*not*turn in source code.*who has not taken this course*to easily implement your algorithm—in*their*favorite programming language, not yours.**Omit all irrelevant details.**Don't turn in the piece of paper you used to figure out your answer; copy the relevant information onto a new empty page. If the same algorithm works equally fast whether the input is an array, a singly linked list, a doubly linked list, or a binary tree, try to describe it so that a competent programmer can easily use any of these data structures.**Give generic solutions, not just examples.**Showing that your algorithm works on specific examples does not prove that it is correct on all inputs. It is good to use examples to illustrate how your algorithm works and provide intuition for your ideas, for the sake of the reader/grader, but such illustrations will not be adequate substitutions for a general argument/proof that your algorithm works on all inputs.**State your assumptions.**Explicitly state any additional assumptions that your solution requires. For example, if the performance of your algorithm depends on how the input is represented, tell us exactly what representation you require. If your solution to a recurrence assumes a particular base case, tell us what base case you require.

**Tentative Grading Guidelines
**(adapted from:
https://www.cs.duke.edu/courses/fall11/cps130/handouts/homeworknote.pdf)

**10: **correct answers and proofs

**4–9: **flawed proofs: confused, missing cases, not
rigorous

**3–6: **right answers, proof outline, but not a good
proof

**2-5: **right answers but no proofs

**1: **tried something correct (e.g., base cases)

**0: **not submitted, or nothing correct

Specific points off:

**1: **minor algebra mistakes

**1–3: **unclear proof

**1–5: **failure to follow
directions (e.g., proving something by one method when the problem asked for
another)

**1–5: **failure to justify a
not-so-obvious step (depending on its importance and difficulty)