Grading Guidelines for Quiz 1 and Lab 1

Quiz 1

• Mean: 17.8 62%
• Standard deviation: 7.2
• Highest grade: 28

Since we're just starting out, I tried to be somewhat lenient -- especially with stuff like spaces, quotation marks, etc. Also, since we have been using "seqneuces" and "lists" somewhat interchangeably, I'll accept either one for the answer.

Question 1: Most people didn't have problems with this one. There was some confusion on the exponential and the string slicing, but nothing that I would consider to be major misunderstandings.

Question 2: I was actually very surprised that so many people were able to get full marks (or close to it) on this question! Most of you know how to trace a loop properly and work out the loop indices. The main difficulties that I saw were forgetting that string multiplied by a number creates a longer string -- those I'm going to chalk up to forgetfulness rather than conceptual understanding problems.

Question 3: This one is a step up in difficulty level, but we went over this in class and I hope that it's less intimidating now. The way that I graded was this:

• points are given if you can get input from the user
• points are given for remembering that input from the keyboard is a string (either using int() to convert it, or using input() -- though I didn't teach you the latter)
• points are given for having a for loop

If your program did all the above and your loop has a correct range, then you start getting above the 50% mark. The rest of the points are given for correctness (like being able to generate the odd and even numbers correctly.) I did not pay too much attention (this time) to the print format.

Lab grading guidelines

In general, if your program does not compile (i.e. won't even start running), then you will receive no points for the program. If it runs properly, then you canexpect to have at least passed the lab -- i.e. to get at least 50% of the marks. Anything above and beyond that will require the following:

• Comments.
  • Your programs should start off with a header that states your name, the date, and what your program is supposed to be doing.
  • Inline comments: If there is something in your program that is hard to understand (for a third-party who knows Python but does not necessarily know what you are thinking), please comment and explain.
• Use variable names that make sense. Please. No x and y. In general, somebody else should be able to know what your program is doing just by reading the code. The comments are supposed to be supplementary only.
• Where possible, try not to use hard-coded values once the computation begins. Store your hard-coded values in variables at the start of your program, and use the variables instead. It makes it a lot easier to understand what you are doing.

Since this is the first lab in which we're grading in this way, we have tried to be somewhat lenient, especially with comments. However, starting from this week's lab onwards, we will start enforcing these grading guidelines. You still have 2 more days to go back and fix your code, so do it!

By popular demand, here is an example of what we mean by good commenting and good variable names (walk.py). Note that not every programming statement needs to be commented, but between the combination of good variable naming and comments, it is fairly easy to figure out what the program is doing.