CSC 160 Grading Policy

The floggings will continue until morale improves.

-- Management

Timely Grading

Our goal is to return grades in a week or less, at least for the programming exercises. The more significant projects may take a little longer. We believe that quicker feedback is better.

Late Work

See below.

Multiple Submissions

Multiple submissions are allowed (even encouraged), but cause trouble. Main problem in 2011 was later blank hand-ins "masking" TA attention from earlier attempts.

  1. Ideally, we grade the most recent complete assignment (.pdf or .zip).
  2. If there is no complete assignment, we look to see what is gradable and grade that (or at worst them).
  3. Whatever, the latest time of submission for what's graded is the time that counts for the whole assignment.
In short, we should try to find what the student would graded and grade that.


All 160 grades are based on programming, laboratory projects, and possible exams, including Success Facilitation Surveys.

Usually projects are individual (not a team). The data acquisition projects need teams of two.

Projects in the second half of the course include project writeups, which can represent a significant fraction of the grade. Projects will be weighted more than programming exercises when computing final course points, though the 0-3 mark system still applies (see below).

For the relative grading weight of project writeup and "everything else" (like code), see The Universal Hand-in Guide, which also states what to submit and and how to submit it for each project.

Grading Code and Readme Files

For the non-laboratory projects (Pi, Gauss, Model-Fitting, ODE), the assignment contains a list of functions to be written, along with their function prototypes and purpose.

We will check for:

  1. All requested functions are written according to specifications.
  2. There is at most one script file. It defines values, perhaps gets input, and calls functions. It has no for-loops or if-else statements, just sequential instructions.
  3. Each function is commmented below its first line, giving semantics of function and its input and output variables.
  4. All variable names are semantically meaningful.
  5. Using more functions than are asked for is fine.
  6. Each function is in its own .m file
  7. Each function should be easy to understand and ideally easily seen to be correct. So small, elegant, with good choice of names.
  8. The Readme file lists all .m files and a one-sentence description of what the function or script does. It also says how to use your program. If one just executes a main script, say that. Or if user needs to provide input, describe that. It also documents any bugs that you know of. Run-time errors will cost you fewer points if you document them and you show that you know their cause.

Project Writeup

You might want to check out The Writeup Lecture, which has many useful pointers, including previous 160 Project Writeup samples. Also see the Universal Hand-in Page for expectations about particular projects.

When grading project writups, we'll check for the following: each should be given a separate section of the paper, with appropriate section heading.

  1. Title, Assignmnent Information, your name as author or the members of your team if this is a LAB report.
  2. Goal: briefly state what you tried to do. If the original project assignment was followed exactly, you can just point to it, but a nice self-contained motivation and description of what you hope to accomplish is always good. If you interpreted the assignment, changed it, did suggested or new extra work, or avoided anything, say what.
  3. Methods: describe your implementation, algorithms, underlying math, whatever helps us understand technically how you went for the goal. If applicable, include a short description of the structure of your program and the algorithms that you used. This section tells the reader what you did, so be explicit about your methods especially if you did something especially novel, cute, or complex.
  4. Results: The results depend on your goals, so need explaining in that light. Typically these assignments provide a chance to create graphics or tables, and to draw conclusions (for instance, by comparing performance or result statistics from different program inputs or versions.) Don't ignore any opportunity to design and perform experiments with instrumented code and to present and analyze the results. Output from test cases, images or sound samples, or transcripts can be appropriate as well. Nice graphics are not just good, but expected.
  5. Discussion: Often projects call for interesting techniques (hence references), cause difficult technical problems, and suggest further work. Often results and methods can be compared to data or techniques from related prior work found in the literature (and a great source of always-good references). Put all such commentary here, not mixed in with results or goals.
  6. References: Always good, they make you believable. In a pinch, reference textbooks. References to websites are always suspect, but web can help you find published versions of papers to reference.
  7. Style:
    1. Organization: use headings and subheadings.
    2. Good English (active voice, correct spelling, punctuation, and grammar.)
    3. Correct and consistent use of technical terms.
    4. References (always good -- see references as content below).
    5. Professional formality. We're not going to try to define this. Some writeup samples are not really sufficiently formal. Strive to be professional, as in A Mech. Engg. Report .

Marks and their Meaning

Programming Exercises and Projects

Programming Exercises get one mark, Projects get two, one for code and one for writeup. The relative weighting of these marks is given in the Universal Hand-in page.
Marks are one of 4, 3, 2, 1, or 0, as described below.

Success Facilitation Surveys

Marks mean:
0 nothing handed in
1 only signature is right
2 fair to good: better than wrong, worse than very good
3 very good, excellent, perfect

Final Grade Calculation

100 course points are possible for the course, and this total of 100 is a weighted sum of all the marks for all BB submissions and SFSs. As of now, we plan to weight the projects (From Pi Project onwards) twice as much as the programming assignments (1 to 5).

Given the total possible points for projects, code, and programming, SFS performance will be weighted a significant fraction (in fact, 10%) of that. The effect will be that blowing off the SFSs costs about a letter grade.

The translation of course points to letter grades is done when all grades are in. We use a spreadsheet that combines all available marks and appropriate weightings (as advertised in the universal hand-in page or consistent with this section). The number from that (total course points out of 100) is interpreted by the professors and translated into letter grades.

Partial Credit

The writeup is a good chance to get partial credit: In case you have not completed the project, you should mention in significant detail:

This will allow us to give you partial credit for the things you have completed.

Extra Credit

Give a clear description of any extensions or special features of your project. This will be used for assigning extra credit. Some extra credit ideas are mentioned in the Scheme, C, and possibly Matlab projects. Extra credit will be considered after making the first cut at letter grades for the course. If you're near the top of your bracket, or the amount of extra work you've done is particularly large, you can expect it to push you up a grade.

Late Assignments

Late assignments will have one mark deducted for each day or part of a day (that is, "rounded up") after the due date that the assignment is late, with a limit of 2 days, after which the assignment will disappear from Blackboard. After that, late homeworks will not be accepted.

So submitting more work after the deadline could be a win but only if the new work adds at least 2 marks to the pre-deadline mark.

If you need an extension due to personal problems, please obtain the permission of the instructor and then email the TAs and cc the instructor with the new arrangements you've agreed to.

Repeating previous suggestion: if you are not going to have the project completed on time, take the time to work on your writeup (as described above). It is possible that you will get significant (up to 50%, or possibly more) credit even if your program does not work.

Procrastination is a common time-management tool. However I suggest you don't wait until the last minute to start or complete your assignments. First and most likely, the assignment may be flawed due to typos, system incompatibilities, whatever: the quicker you do sanity checks the earlier we can deal with such problems. Second, it may take some time for the ideas to sink in. Third, if you start early you can ask questions of the TA or your buddies. Fourth, there could be machine failures or unforeseen personal circumstances. Fifth, do you really think an extension is a good idea? Now you've twice as much to do this week -- remember: "Any fool can drown." You really don't want to get behind in this course.

Academic Honesty

Student conduct is governed by the College Academic Honesty Policy, the Undergraduate Laboratory Policies of the Computer Science Department, and the Acceptable Use Policy of University Information Technology services.

The following are additional details specific to CSC 160.

Unless otherwise stated, all assignments, exams, and SFSs in CSC 160 must be strictly individual work.

Collaboration on homework and programming assignments is encouraged at the level of ideas. Feel free to ask each other questions, brainstorm on algorithms, or work together at a blackboard. Be careful, however, about copying the actual code for programming assignments, or copying the wording for written assignments.

Copying code or written text is generally NOT acceptable. This sort of collaboration at the level of artifacts is technically permitted if explicitly acknowledged, but usually self-defeating. Specifically, you will get zero points for any portion of an artifact that you did not transform from concept into substance by yourself. If you neglect to label, clearly and prominently, any code or writing that isn't your own, that's academic dishonesty, which is worse.

Back to the course home page
Last Change: 04/20/2011 RN