Rubric: Problem Sets
For grading the weekly exercises.md problems. The exercises span several types (the book tags them),
and each type is best graded a little differently. A per-problem points scheme plus these type-specific
expectations keeps grading consistent.
General per-problem scale
| Level | Points (of 10) | Meaning |
|---|---|---|
| Excellent | 9–10 | Correct, complete, in modern style, with reasoning shown. |
| Proficient | 7–8 | Correct result, minor style/clarity issues or a small gap in reasoning. |
| Developing | 4–6 | Partially correct; a conceptual error or incomplete work. |
| Beginning | 0–3 | Incorrect or largely missing. |
Type-specific expectations
"Type, compile, and run" (predict-then-run)
Full marks require the student to state the predicted output first, then confirm it. Grade the prediction and the confirmation — a correct program with no prediction is Proficient at best, because the point of the exercise is reasoning about output, not just producing it.
"Port it" (translate from Python/MATLAB and compare)
Require: a correct Fortran translation in modern style, a working compile, and a reported comparison (timing or a note on why Fortran is faster here). Docking the speed comparison is the most common reason to drop from Excellent to Proficient.
"Find the bug"
Require both the diagnosis (what is wrong and why — e.g., "integer division truncates", "loop order
is row-major", "missing intent(out) initialization") and the fix. A fix with no explanation is
Developing: guessing correctly is not understanding.
"Modernize it" (FORTRAN 77 → modern)
Grade against the eight-step recipe of Chapter 18: implicit none, free-form, COMMON→module, intent,
assumed-shape, structured control flow, EQUIVALENCE→types, error handling. Full marks require that the
modernized code be numerically equivalent to the original (the student should say how they checked).
"Design it" (extend the solver)
Grade with the project rubric's design and style lenses at a smaller scale: does the addition fit the existing module structure with a clean interface?
"Back of the envelope"
Grade the reasoning and order of magnitude, not the exact number. A well-justified estimate that is off by a small factor is Excellent; a precise-looking number with no visible reasoning is Developing.
Conceptual / short answer
Grade on correctness and precision of claim — the book's honesty ethic applies to students too. "Fortran is fast because it's low-level" should lose points even if the surrounding answer is otherwise fine.
Logistics
- Solutions: daggered (†) and odd-numbered problems have published solutions in
appendices/answers-to-selected.md— assign the even, un-daggered problems for graded homework, and use the solved ones for practice or worked examples. - Code submission: require that submitted
.f90files compile withgfortran -std=f2018 -Wallwith no warnings; a warning-free build is part of "modern style." - Collaboration policy: discussing approaches is healthy; submitted code and write-ups must be the student's own. The "explain your fix / your prediction" requirements make copied work easy to spot.