## Collaboration

Be sure to read the collaboration policy on the syllabus.

## Results from Class

Unless otherwise stated in the problem, you may use results, algorithms, and data structures from class and from 332 as though you had a library function. A list of what you can use from 332 is

here.
- For example, "run the Gale-Shapley algorithm with the riders proposing" or "run the propoal algorithm from Lecture 1"
- For example, "let Q be a heap-based priority queue" or "let D be an AVL-backed dictionary with ints for keys and vertex objects for values"

## Grading

### How much detail do I include?

When writing pseudocode, your target audience is a competent programmer who has taken a course like CSE 332 (i.e., the other students in this course). But has only just read the problem that you are solving. Remember that you have probably thought about a problem for at least a few hours by the time you are writing up a solution. Your reader has **not** -- you have much more intuition than they do.

A good check is to ask "would me from last week understand this solution?" and "would me 6 months from now understand this solution?" If not, you are probably relying too much on the intuition you developed, and you should make that intuition explicit.

Our solution for a problem will always fit on one printed page (in LaTeX). It's ok if your solutions are a little longer (it's generally preferable to include too much detail than too little), but they shouldn't need to be much longer than a page.

### What if I'm not sure how to do a problem

Usually, grades for problems go in approximately this order:

- A correct and efficient algorithm.
- An algorithm that is as efficient as the intended solution, and has the main idea of the problem, but mishandles some edge cases.
- An algorithm that is not quite as efficient as the intended solution, but incorporates some of the algorithm design principles that are relavant (e.g., is not just a brute force solution).
- An algorithm that is fundamentally incorrect or signficiantly less efficient than the intended solution or is just a brute force solution.

When designing rubrics, we generally intend it to be to your benefit to have significant, but incomplete, progress toward a correct solution, than to write an incorrect algorithm and intentionally write an incorrect proof.

It is **extremely** common for our problems to have more than one reasonable solution! If we tell you to use a particular technique, you must use that technique. But otherwise we accept any correct solution.

### What about style?

We have a

style guide!