|Computer Science CS 337|
|Intro to Semantic Information Processing||Fall 2000|
Assignment 2 is due on Tuesday. Nancy Hacker wants to turn on the assignment on time, but she is not quite done. After reading the submission guidelines, she figures out that she has a free bonus day, so the assignment is really due on Wednesday. Moreover, it is on hacker time. 5AM Thursday is still Wednesday for people who live fast and work late. If she turns in the assignment after 5AM Thursday, she will lose half of the points.
Nancy also understands that she has to prove that her program runs. Being a sensitive hacker that she is, she knows that she has to include sample output, AND she has to make it easy to read, otherwise the TA gets pissed off.
She sends in the assignment by email before 5AM
Thursday and she puts the paper copy in the mailbox "Shamma"
when she happens to be in the CS department.
The long version:
You have to hand in assignments BOTH in hardcopy and by email. The hardcopy should be the printout of the file attached in the email. Those two submissions should be completely redundant. The email has to get in by the deadline, and you can place the hard copy in my mailbox (shamma) when you come for the next class or before. One exception is the Ambiguity assignment that can be handed in hardcopy only.
Email submissions to email@example.com with the subject line "Assignment #x" where x is the number of the assignment.
You should attach ONE document containing your entire assignment to the email. The document name should beAxlastname_firstinnitial and whatever extension is appropriate. x stands for assignment number. So, for assignment 3 I would send an email with the subject line "Assignment #3" containing the file A3krema_m.doc.
I take 5 points off all the submissions that do not follow these rules. So think a bit before you send.
That said, programs are ultimately a medium of communication. Obviously, a program has to explain to the computer how to do a specific task. However, programs are also a way of communicating with other people. A program needs to express how it works to the person reading it well enough that they can safely and efficiently fix or extend it. In this class, the person reading it will most often be the TA, but in real life, it will be your coworkers, your boss, or even you yourself. (If you don't think that it should be hard to understand a program that you wrote yourself, try going back and reading your old A11 problem sets and see if you understand everything your old code was doing).
For this reason, you should approach writing your program as you would writing an essay for a composition class: it should be clear, concise, and precise. Again, we have no fixed coding standards for the class. We will not make you fill in a specific boilerplate comment at the top of ever procedure, force you to comment every ')' or '}' with an annotation about what statement it is closing off, or make you start all of your integer variable names with "i" and all of your floating point variable names with "f", although we know people in industry who do all of the above. Instead, we have a simple rule for coding style:
Note that sometimes adding more comments makes a program less readable. If you find yourself commenting a line like
(setf a (+ b c))
with a comment like "set a to the sum of b and c", then you're going overboard.
Finally, there are a few style issues that we will penalize you for:
(defun my_ai_program (args) (let ((foo)) (do some amazing stuff ... ... ... ) (return the_right_stuff))) ;; program call and input here ;; output here - after the program!!
In addition to these guidelines, you need to follow the
guidelines for each assignment.