Grading Standards for CSC 162

Spring 2010

End-of-semester numeric scores will be weighted roughly as follows: 

class participation 15%
programming projects 25%
labs   20%
workshop attendance   5%
midterm exam 15%
final exam 20%

Letter grades will be assigned by subjectively identifying brackets in the numeric scores.  There is no pre-determined curve.  In particular, I have no objection to giving all high grades (or all low grades) if it seems appropriate. 

Class attendance and active participation are mandatory.  Please arrive on time.  I expect to start at 2:00 sharp, and late arrivals disturb the folks who are already there. 

Assigned reading in the text is also mandatory, and must be done before the associated lecture.  I’ll be posting commentary on the textbook to Blackboard; please peruse this as you do the reading.

If there is anything you don’t understand in class, please stop me and make me explain.  Typically you will find that half the class is similarly confused, and grateful to have you ask.  (Likewise, if I’m belaboring something that everyone understands, please prod me to move on. )

My lecture notes are available on-line, but please note that they come with no guarantee.  In particular, I reserve the right on exams to ask about anything I’ve covered in class, even if it isn’t in the book or lecture notes. 

Homework Projects

Tentative plans call for a programming assignment roughly every two weeks, all (or almost all) in Python.  The workload should be comparable to, or a little heavier than, CSC 161.  The concepts will definitely be more conceptually challenging.  Don’t procrastinate!  Start every assignment well ahead of time, and be sure to read all on-line documentation carefully. 

For some assignments you may have the option of working in pairs.  You can also work alone if you prefer.  In most cases the partners in a pair will receive the same grade, but I reserve the right to assign different grades if I have reason to believe that partners did significantly different amounts of work.  Team membership will be self-selected, and can vary from assignment to assignment. 

Assignments will be turned in via Blackboard.  Late-breaking updates from the TA or professor will be posted there as well.  We will strive to grade assignments within one week of the due date, at which point grades will also be available on Blackboard.  Additional information may be sent to you via email.  If you have any questions about your grades, see the TA or, if she is unable to resolve the issue, the professor

You are encouraged to share ideas with fellow students, but only one person or team can get credit for actual code (see the course rules for academic honesty). 

README files

With each assignment you must include a README file that contains whatever information you think might be needed for the TA to understand (and evaluate) your code.  Much of this information may be included on the original assignment web page; you only have to fill in the parts we didn’t provide for you already.  Information you might consider includes

How to use your program—
details on calling conventions, input and output data formats, limitations, bugs, and special features.  Explain both the negative aspects of your program (limitations, known bugs) and the positive aspects (extensions, special features).  If you don’t include the former, we will assume you didn’t realize the limitations were there.  If you don’t include the latter, you may not get extra credit. 

How your program works inside—
your choice of modularization (abstractions), data structures, and algorithms.  Be sure to explain anything you did that is likely to be different from what other students may have done, and justify any design decisions for which the rationale isn’t immediately clear. 
Your write-up should be coherently written, using full sentences and paragraphs.  This writeup need not necessarily be long, but it is important.  All writeups must be in plain text (README.txt) or Adobe PDF (README.pdf) format.  Other formats (e.g., Word or postscript) will not be accepted. 

Grading scale

For each programming project, points will be divided roughly 80/20 between the code itself and the README file.  A more detailed breakdown follows: 

No Late Assignments

It is my strict policy not to accept late assignments.  Exceptions will be made only under the most dire of circumstances.  Note, however, that I am extremely generous with partial credit, so turn in what you have.

Every semester I have students who let a due date pass.  When I ask them what happened they say “Oh, I didn’t finish, so I didn’t turn anything in.”  Then I have to give them a zero.  If they had turned in even some reasonable preliminary stab at the project they could have received a substantial fraction of the total points.  This can easily make the difference between letter grades at the end of the semester. 

So if it looks like you aren’t going to make a due date, don’t keep debugging down to the wire.  Stop an hour early and take the time to organize what you have and put together a write-up that presents it in the best possible light.  Your transcript will love you for it. 

Extra Credit

There will be opportunities for extra credit on most of the programming projects and exams.  Extra credit will be considered after making the first cut at letter grades for the course.  If you’re near the top of your grade bracket, or the amount of extra work you’ve done is particularly large, you can expect it to push you up a grade. 

Academic Honesty

Student conduct in CSC 254 is governed by the College Academic Honesty Policy, the Undergraduate Laboratory Policies of the Computer Science Department, and the ResNet Acceptable Use Policy.  I helped to write two of these policies myself.  I believe in them strongly, and will enforce them aggressively. 

The following are additional details specific to CSC 162. 

Exams and review questions must be strictly individual work. 

Collaboration on programming assignments among team members is of course expected.  Collaboration on assignments across teams is encouraged at the level of ideas.  Feel free to ask each other questions, brainstorm on algorithms, or work together at a whiteboard.  You may not claim work as your own, however, unless you transform the ideas into substance by yourself.  Among other things, this means that you must leave any brainstorming sessions with no written notes

Students are expected to take reasonable precautions to protect their code from accidental or deliberate access by others. 

For purposes of this class, academic dishonesty is defined as

I work under the assumption that students are honest.  I will not go looking for exceptions.  If I discover one, however, I will come down on it very hard. 

Last Change:  26 April 2010 / Michael Scott's email address