
Homework Guidelines for
CSC
244/444
There will be 6 assignments (sometimes handed out in two parts:
programming and analytical), one midterm and a final exam. The assignments will count 10% each,
midterm 15% and final 25%. CSC 444 will have a few additional
questions on the assignments and will need to complete an individual
course project.
Assignments are due by 5 PM.
Written assignments should be placed in my mailbox (the mailroom is
usually locked at 5). I will collect the assignments soon after 5.
Programming assignments should be turned in using my turn-in script:
/u/zhanghao/bin/TURN_IN
You should first put everything to be submitted into a directory, in
which there must be a file named README.
Then, running
/u/zhanghao/bin/TURN_IN dirname, where
dirname is the directory of your files
will cause the entire directory being submitted.
The policy for late submission is that for each 24 hours of delay after
the due date, 10% of the full
score will be substracted. So, 0.9, 0.8, ... are the subsequent
multipliers.
If you need an extension, please write an email before the deadline to
let me know how long an extension you need. However, an extension
cannot be so long as to be interfering with feedback. Roughly speaking,
extensions of more than 3 days are not acceptable. Only under certain
circumstances, there can be
penalty-free extensions applicable to all the class members. Such
extenstions will be announced at least 2 days before the respective
deadlines. You should always plan ahead, recognizing that the time to
debug programs is highly unpredictable. Excuses concerning why your
last minute rush to complete the assignment was thwarted will not work!
Writen assignments can be either hand-written or typed. Readability is the the basic
requirement. In this course, the written assignments will involve
logical expressions, formal proofs, networks, etc. Too many
crossing-outs or
corrections will make them hard to follow. So, you should be nice to
your grader!
For a programming assignment, a write-up that can help the grader to
understand your program is required. Depending on the complexity of the
task, about 20-40% of the grade will be
allocated for the quality of your write-up and the readability of your
code. The detailed requirements for write-up and programming style are
as follows:
Write-up requirements:
Please include the following in your writeup
- A checklist of all the submitted files, with short descriptions
of contents, if this is not evident from the names.
- General description of the algorithm. I must to be able to get a
good idea of how your program works without going through the code.
This includes explaining design choices like storing data in a hash
table vs a list.
- Test examples to demonstrate that your program works and that you
understood the problem and thought about different possible inputs. I
have to be able to answer the question "If the program does not work
properly on my test data, in which cases it does work?."
- Documentation for boundary cases. In general, you can assume that
you're given the right type of argument - if you expect a list, you
won't be given a string. But you must be prepared to handle special
cases such as an empty list. You are required to tell me what the
expected behavior of your program is in these cases.
- Known problems. If your function has bugs you didn't have time
to fix - document them. You'll get more points than if I discover them
myself.
- Answers to any questions asked in the assignment.
Also, if you're running out of time and cannot implement something,
describe in more detail how you would have done it - you may get credit
for this, too.
Programming style requirements:
- All your functions must conform to the specifications in the
assignment. This means that you use the function names specified in the
assignment (if any), and both input and output value types must be the
same as specified in the assignment. If you are allowed to choose an
input/output data format, it should be simple to read and write, such
as a list. However, for efficiency reasons, you may still need to use a
complex data format internally, such as a hashtable, thus you would
need to do data conversions in such cases to guarantee both friendiness
and effiency of your program.
- Follow the usual
good style guidelines, which includes comments
or self-documenting variable names, and avoiding obscure programming
constructions. In particular, programming constructs that make your
code more difficult to read are
- General loop operator "DO" - use "DOLIST", "DOTIMES",
"MAPCAR", or recursion instead.
- Property lists.
- Progn. You should never need it. If you feel you need it
with "if", don't use if, use "cond" if you have 2 or more branches, and
"when" for a single branch.
- prog, go, tagbody and other goto-like constructs. goto is
bad in any language. It is next to unreadable in LISP in most cases,
and there are absolutely always better substitutes.
- return and return-from. They are OK in a small (just a
couple of lines) function. For larger functions, returns from the
middle are bad style even in procedural languages. In LISP, you're
almost always better off with recursion or filtering your results
afterward.
- Indent your code appropriately. The default indentation provided
by emacs is good.
- Declare all your variables. The global variables are declared
using "defvar" or "defparameter", and the locals are declared using
"let". You will lose points for undeclared variables, especially if it
interferes with global variables I set for testing. As in any
algorithm, you should only make the variables global if there are good
reasons for that, and motivate your decisions in the algorithm.
Tip To check for undeclared variables, do :cl filename
in allegro CL, it will compile the file and produce warnings about
"free references to variables".
- Don't replicate existing functions. Lisp has an extensive
library of functions to work with sequences (which include lists).
Learn how to use mapcar, find, find-if, remove, remove-if, position,
replace, reduce, assoc, acons.
- Do not put print statements in your functions, unless the
assignment explicitly requests it. For the most part your input is
entered as function arguments and your output is just the result of a
function you execute. The only exception is if you need to pretty print
the complex data structures which are not printed nicely by the default
LISP printer. If this is the case, you should write one function that
produces the result, and another that can interpret and print it
nicely. When asked to get some timing results for functions you write,
never time the functions that do any output - it is extremely slow in
LISP and the overhead will completely cover the computation time.
Homework Statistics for
CSC
244/444
|
444
|
244
|
HIGH
|
AVERAGE
|
HIGH
|
AVERAGE
|
1-A
|
105
/ 100
|
89.1
/ 100
|
93.9
/ 100
|
85.5
/ 100
|
1-B
|
94
/ 100
|
82.8
/ 100
|
97
/ 100
|
79.6
/ 100
|
1
|
|
|
|
|
|
|
|
|
|
2-A
|
77
/ 80
|
70.2
/ 80
|
63
/ 60
|
51.9
/ 60
|
2-B
|
90/100
|
76.3/100
|
97/76
|
60.9/76
|
| 2 |
|
|
|
|
|
|
|
|
|
3
|
102/105
|
94.8/105
|
98.0/100
|
74.3/100
|
|
|
|
|
|
midterm
|
77/100
|
66/100
|
88/90
|
58.1/90
|
|
|
|
|
|
4
|
96/100
|
80.5/100
|
104/100
|
58/100
|
Many
Thanks to Myrosia Dzikovska
last
updated on December 7, 2004
zhanghao @ cs ...


URCS People |
URCS Home Page