This is the grading rubric for problem-set hand-ins for CS 252. Please also see the Homework Guidelines and Feedback Key for additional information regarding the evaluation of problem sets.
This rubric is focused mostly on algorithm-design problems. For such problems, the required components of a solution (referred to below as the “components”) are:
Rather than asking for an algorithm, some questions may instead ask for a counterexample or proof of a given statement, or may be multi-part; in these cases the required components should be clear from context.
Each problem is scored on a 24-point qualitative scale. The number of points for each rating is indicated in parentheses in the table below. The total score is computed as follows:
Score = (Correctness + Style + Clarity + Precision + Conciseness) × Completeness
The sum in parentheses will be ≤24, and the Completeness score is a fraction out of 24. Fractional total scores are rounded up. Remember that the total score, as a percentage, does not map directly onto a letter grade; these are qualitative scores.
Each submission receives only one score per category; this means that multi-part questions are evaluated as a whole. In multi-part questions, the scores will be roughly the average of the scores that the individual parts would receive: that is, great work in some parts can offset so-so work in another.
The grading avoids “double jeopardy”: errors count against the rating only for one category, unless they're egregious. (For example, style issues may affect clarity, but unless something is seriously going wrong, this will be noted only in the rating for either style or clarity.) In particular, if a section is incomplete, this affects only the Completeness rating, and does not affect the rating for the other criteria at all.
| Criterion | Great | Good | So-So | Poor |
|---|---|---|---|---|
| Completeness | All components are present and complete. (24/24) | All components are present, but some are somewhat incomplete. (21/24) | One or more components are missing, or all components are severely incomplete. (16/24) | No genuine attempt at a complete solution. (8/24) |
| Correctness | All components are completely correct. (10) | At least one component contains a minor error. (7) | At least one component contains a major error. (4) | Multiple major errors, or an entirely incorrect response. (0) |
| Style | A professional, polished tone and format are maintained throughout the solution. (3) | Minor issues of tone, voice, spelling, punctuation, or formatting. (2) | Major tone or presentation issues. (1) | Exceedingly terse, sloppy, or otherwise unpolished writing. (0) |
| Clarity | All components are clear, organized, and easy to follow. (4) | Occasional or minor issues of clarity, causing confusion that can be overcome by careful reading and charitable interpretation by the reader. (3) | Truly confusing writing that can only be interpreted with significant effort. (1) | Exceedingly confusing writing. (0) |
| Precision | No meaningful ambiguity. (4) | Occasional or minor issues of precision, causing meaningful ambiguity that can be overcome by charitable interpretation by the reader. (3) | Major precision errors that cause meaningful ambiguity in the interpretation of the solution, which can only be resolved with difficulty (if at all). (1) | Severely underspecified instructions, definitions, claims, or arguments. (0) |
| Conciseness | Direct and to the point. (3) | Occasional extraneous writing. (2) | Very long-winded, redundant, or extraneous writing. (1) | Exceedingly longer writing than is necessary. (0) |
A little further elaboration on the characteristics of “great” writeups:
| Completeness | Sometimes the running time is relatively obvious, and in this case a thorough proof of running time is not necessary. |
|---|---|
| Style | A couple typos are acceptable, as is the occasional non-distracting lighter-toned aside. |
| Clarity | In a clear write-up, each component of the solution is organized and easy to follow. The different components are easily distinguished, and the purpose of each bit of writing is apparent. Variables in clear pseudocode are easy to understand, because of preceding explanatory prose, comments, and/or self-explanatory variable names. |
| Precision | A precise write-up leaves no meaningful ambiguity in the interpretation of the algorithm or the arguments about its properties. Note, however, that the audience for each solution is not a robot, but instead a well-informed, but skeptical, human reader. Many forms of presentation that would be “ambiguous” or “underspecified” if we were writing code to be run by a computer are nevertheless acceptable in these solutions. So long as the solution is comprehensible and specific enough that the reader could easily write a correct implementation of the instructions, or could easily flesh out the pedantic details of the argument, it is just fine. |
| Criterion | Minor | Major |
|---|---|---|
| Correctness | Incorrect values for constants; minor unconsidered edge cases; minor gaps in logic. | False-positive or false-negative outputs; large portions of the input space that are not handled correctly by the algorithm; running time that does not meet the requirements of the problem statement; major gaps in logic. |
| Style | Provisional or passive voicing; smarmy or pompous voicing; occasional distracting lapses in professionalism. | Consistent errors of capitalization or punctuation; consistently un-professional tone; major errors in formatting. |
| Clarity | Disorganized or hard-to-follow arguments or explanations; confusing variable names or pseudocode style; obscure or needlessly complicated pseudocode structure. | Severe instances of issues described to the left, causing confusion that can only be overcome with significant effort on the part of the reader. |
| Precision |
In algorithm statements, meaningful lack of specificity regarding: order of operations, definitions of variables or terms, data-structure implementation or initialization, implementation of non-trivial steps described in prose, minor off-by-one errors, non-catastrophic out-of-bounds errors, and similar logic issues. Also: the use of programming constructs that are language-specific, or pseudocode that otherwise leans too heavily on high-level convenience functions built into some languages. In arguments: imprecise definitions or claims. In running times: missing terms that ought to be included, or inclusion of dominated terms that ought to be left out. |
Severe instances of issues described to the left, causing unresolvable ambiguity. Use of an abstract data type without specifying the implementation, when multiple reasonable implementations exist whose performance characteristics differ. |
| Conciseness | Prose that describes the design process for the solution rather than the idea of the solution itself; prose that is redundant with existing pseudocode and that does not serve clarity; prose that could be replaced with significantly more concise pseudocode; pseudocode that could be replaced with shorter prose without sacrificing clarity or precision; the repeated use of words where mathematical notation would serve just as well; or pedantic inclusion of unnecessary details in description or argument. | Severe instances of issues mentioned to the left, resulting in a write-up that is much longer than necessary. |