Instructor: Lenhart Schubert
See his class page.
TA: Jonathan Gordon
–
Office hours: Friday, 2–3:30 and by appointment, in
Instructor: Lenhart Schubert
See his class page.
TA: Jonathan Gordon
–
Office hours: Friday, 2–3:30 and by appointment, in
Written assignments can be submitted in person during the class when they are due. They can be submitted before the deadline by putting them in my mailbox (in the Computer Science Dept mail-room, CSB 727).
Programming assignments are submitted using the turn_in
script. For undergraduates, this
is /u/cs244/turn_in directory. For graduate
students, this
is /u/cs444/turn_in directory.
Here, directory is the name of the directory that
contains:
Note that the submission script requires a README file, named README, README.txt, or README.md; it won’t let you submit if it can’t find this.
You don’t need to be in the department to submit your work: You
can use scp to copy your work to one of the department
machines and then connect with ssh to submit. Clients for
scp (or SFTP) and for ssh logins are available
for all platforms. (Of course, they’re preinstalled on Linux and
OS X.) For grad students, connect to cycle1.cs.rochester.edu. For
undergrads, connect to cycle1.csug.rochester.edu.
If there is any difficulty submitting your assignment, email it to me before the deadline to avoid late penalties.
Late assignments will be accepted but will incur a 10% grade reduction per day (counted as 24 hours from the time it was originally due). Late submissions will not be accepted once it is necessary for me to distribute grades or discuss solutions. To turn in late work without penalty (e.g., due to illness), you must have permission of the instructor.
Your work must be legible. I suggest type-setting your work (ideally with LaTeX), but if you do so, be sure to allow enough time.
progn. If you’re tempted to use
it inside if, use cond or when
instead. Deeply nesting ifs will lead you into confusion and
bugs, as will prog, go, and
tagbody.Students are taught that it's important to comment everything … But the purpose of commenting can be lost in blindly following rules. Comments are meant to help a reader understand parts of the program that are not readily understood from the code itself. As much as possible, write code that is easy to understand; the better you do this, the fewer comments you need.
– Brian W. Kernighan and Rob Pike, The Practice of Programming
Comment your code thoughtfully.
At the beginning of a function, give a brief, intuitive statement of its purpose and its intended output or effect. If you find this difficult, it’s not a coherent function; reorganize. You should also mention the meaning and type of the function’s parameters, unless they are trivial. E.g., if a function expects data in a certain format, like a list of string–number pairs, you should say so.
Needless, superficial comments of the type
;; Print the current value of x (format t "~A" x)
should make you ashamed. The code says as much.
Rather, explain big decisions and anything that might be unclear to a competent – but half-asleep – programmer looking at your code. If any part of your code is so confusing that it requires extensive comments, probably it should be rewritten.
If you simply assume your code works without testing a variety of inputs, you will be very disappointed (in your grade). Be sure to test all boundary cases, e.g., an empty list, negative numbers, etc.
I do not prescribe a testing method, but a good modular testing framework for Lisp is described in Practical Common Lisp. Basically, for each test case you want to print what function and input are being tested, the expected result, an indication of whether the test case passed or failed, and (optionally) the actual result.
You should explain in the test file what the test cases are showing, and you should include enough test cases to satisfy yourself and me that your code works correctly.
Your write-up should include the names of the functions I need to call to test your code along with a description of their arguments, a general description of the algorithm (including any significant design choices or trade-offs such as storing data in a hash table vs in a list), the input and output data format, any known bugs, and the answers to any questions asked in the assignment. If you run out of time and cannot implement something, describe in detail how you would have done so; you may get some credit for this.
There are many fine introductions to Lisp available online. You should try looking at these and see which helps you. If you are confused and cannot find your answer, email me.
I recommend using Allegro Lisp. On the dept machines, this
is alisp. You can download a
free edition to use at home.
Unless you are committed to an alternative lifestyle, using Emacs to
write and debug Lisp will make your life easier. In particular, you should
use SLIME,
which is a Lisp-editing mode. To get started, add
to your Emacs configuration file (~/.emacs):
(add-to-list 'load-path "/usr/grads/share/emacs/site-lisp/slime/") (setq inferior-lisp-program "alisp") (require 'slime) (slime-setup '(slime-fancy))
Undergrads should change the path in the first line to
"/u/cs244/share/slime". To start a session, type M-x
slime (where M is the ‘meta’ key, typically
Esc). To exit this interactive session, type , quit.
244: Mean 87/100, High 100/100
444: Mean 80/120, High 116/120
244: Mean 140/170, High 162.5/170
444: Mean 162/230, High 210/230
244: Mean 91/100, High 95/100
444: Mean 95/100, High 100/100
244: Mean 80/90, High 92.8/90
444: Mean 98/115, High 114.5/115
244: Mean 84/100, High 97.5/100
444: Mean 89/100, High 100/100
244: Mean 86/95, High 93.8/95 (Late assignments were out of 105 points)
444: Mean 100/115, High 118/115 (Late assignments were out of 130 points)
244: Mean 45/70, High 63.5/70
444: Mean 53/75, High 71.5/75
244: Mean 86/100, High 100/100
444: Mean 92/100, High 102/100
244: Mean 93/115, High 108/115
444: Mean 106/125, High 122/125
244: Mean 49/55, High 53/55
444: Mean 56/60, High 58.8/60