All written assignments must be put in my mailbox (in the CS mailroom - CSB727) before the time the assignment is due, or submitted in person during the relevant class meeting.
For each programming assignment, your submission must include the following three separate files (or face grade penalties):
yourCSid_src.lisp
-the source file containing all the code necessary for your solutions to the
assignment;
yourCSid_test.lisp
-the test file containing your test strategies and test cases to demonstrate
the correctness of your code;
README
-the writeup for the assignment.
Additionally, programming assignments should be submitted to me via the TURN_IN script:
Type at prompt (grads):
/u/cs444/TURN_IN <dir>
where <dir> is the directory containing your code
Type at prompt (undergrads):
/u/cs244/TURN_IN <dir>
where <dir> is the directory containing your code
In all cases, you must include a file named README in <dir>, or else your submission will fail.
If you have problems with TURN_IN, please email me and ask for assistance. If it's close to submission time, go ahead and email me your assignment to avoid late penalties.
Generally, source code accounts for about 55%; your test file, writeup, and coding style account for about 45% of the total mark of an assignment.
Please comment your code thoughtfully:
At the beginning of each function, provide a intuitive statement of its purpose, the meaning and kind of value of each of the parameters (with an example if the value has some special form), and the output or effect of the function.
If anything is unclear in the body of a function, explain what is going on. This ranges from places where you are taking cars of cdrs of cars, to places where your recursive solution hinges on the fact that some recursive call has already taken care of the special case that the user might wonder about. When in doubt, comment.
Do not add pointless comments! Don't add a comment like "Sets the car of the caaddr of arg0 to the cadr of arg2". Instead, use meaningful, natural language whenever possible. Often, well-written code requires fewer comments.
You should follow the usual good programming style, giving the functions and variables meaningful names and avoiding obscure programming constructs.
Try to keep your Lisp code to 80 characters or less per line, and indent meaningfully. Sometimes it's tricky, and sometimes it doesn't work, but most of the time it isn't difficult to do so. A bonus is that such formatting makes it easier to to fit two or three vertical windows in emacs on your screen at once.
I should not have to modify any of your source code to grade your submission, especially not to get it loaded into a REPL.
Testing is important. The test file is worth about half as many marks as the code. Include test cases for each problem, and make your test file (*_test.lisp) executable in Allegro Common Lisp. A good, modular test framework for Lisp can be found in Practical Common Lisp.
The basic idea is to print, for each test case:Make sure you discuss your test cases in the test file. You can use the form of a comment for every test case or write a commented paragraph before each function describing your test strategy for the function (Unless it is a trivial function.)
I should be able to tell, after reading your testing document, how well you understood the problem.
Make sure to test all boundary cases (e.g., empty list, symbols, non-empty lists); If you don't, I will, and your program will probably fail with a REPL breaking Lisp error.
Please include the following in your writeup:
the names of all your program and data files, with short descriptions of contents, if this is not evident from the names
the names and types of arguments for functions I have to call to test your program;
general description of the algorithm, including your design choices such as storing data in a hash table vs a list;
the input and output data format;
known bugs you did not have time to fix;
answers to any questions asked in the assignment;
(if applicable to you) which provided solutions (which version, which author, and which previous phase) you have used in your current phase.
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 some credit for this, too.
Late assignments will sometimes be accepted, with a 10%-15% reduction in grade for every day late. Submissions will no longer be accepted once it is necessary for me to distribute grades or discuss solutions. I may refuse to accept severely late assignments [ >2 days ], depending on the time required to grade the particular assignment.
Practical Common Lisp Free online book. Accessible, less technical than most. Good for getting an easy intro to Lisp.
Paradigms of AI Programming - very nice book, worth referring to especially when trying to make a particular program work or work more efficiently.
For gritty details of specific functions, try Googling the function name + clhs, and following the top result. Ex., "rplaca clhs".
On the research network, I use Allegro. The documentation for Allegro is pretty good. It's a good place to look for information about compiling, profiling, and developing with Lisp in the IDE Allegro Composer. It also explains how to run Lisp programs as command line scripts . The Allegro executable on our network is '/usr/staff/bin/alisp'.
On my machine at home, I use CLISP. It's free and open source.