NOTE: This is the TA webpage for CSC 191/291, which covers homework guidelines and miscellaneous tips. For general class information (textbooks, schedule, etc.) see Len's class webpage.

Announcements


Written Assignments


All written assignments must be turned in before the deadline. Please submit them via email (to both graduate students), including the class name, your name, and assignment name in the email so it doesn't get lost.

The written assignments will be graded on the coherence and clarity of your discussions/arguments. Please read the Writing Grading Guidelines to see how this will be graded. This is very high-level and may be fleshed out and refined if deemed necessary.

Please note that the organization of your writing is important to clearly state your ideas, so I urge you to type your homework. It's difficult to perfectly organize your thoughts the first time you are writing them down. Also, if I cannot read your handwriting, I will not be able to give you any points! In general, I will focus on the content of your writing, but errors in grammar and spelling that are distracting or make your writing difficult to understand will be noted in your grade.

Upper-Level Writing Credit

The assignments of students that are taking this class for upper-level writing credit will go through a revision process. The first submission will be on the posted due date along-side the rest of the class. I will have comments on your writing within a week, which I will return to you on the first class that is at least a week after the original submission. You will then have 1 week from the returned date to rewrite/revise the assignment with my comments in mind.

I will usually use a copy of the grading guidelines to give you your feedback, so it's clear where your writing needs improvement. The written assignment grades will be a equal composite of the first submission and the revised submission. The first submission will be graded exactly as the students that are not taking the class for upper-level writing credit. The revised submissions will be graded with a focus on the writing coherence and take into account the improvement made from the first submission.

The last assignment will not have a second submission since there is not enough time to complete the revision cycle. This assignment will be graded as if it were a revised submission, taking into consideration the comments and revisions I have given you throughout the semester.

In order to opt into upper-level writing credit, you must notify the TAs before the submission of the first homework assignment. This is February 18th, 11:00am. If then you decide to opt out of it, you have until end of day, March 29th to notify us. This will give you the the weekend after receiving the post-revision grades from the second homework assignment to decide whether you'll be able to manage the extra work. This deadline is in place to limit the amount of wasted TA effort since providing feedback and grading the revised assignments add a considerable amount of work. NB: This was updated from the prior opt-out date of March 15th due to the limited writing that was involved in the first assignment.

Lisp Assignments


Lisp assignments must be completed in SBCL, the de facto open source Common Lisp distribution, unless the assignment requires the use of existing code in another distribution (i.e. GridWorld code is written for Allegro Common Lisp). This is for streamlining tests.

You will submit one tarball via email to all TAs (see emails at the top of the page). The tarball will consist of the following three files:

You tarball should be named: [firstinitial][lastname]_[assignmentname].tar.gz. In case you don't know how to create a tarball, here's an example. Consider that I have a folder called Lisp1 in the current directory. Then I can use the following command would create a tarball named gkim21_lisp1.tar.gz:

tar -czvf gkim_lisp1.tar.gz Lisp1

If for some reason creating a tarball is not possible, a zipped folder with the same naming conventions and organization is also acceptable.

Code functionality accounts for 60%, your test file 20%, writeup 10%, and coding style 10% of the total mark of an assignment. These numbers subject to change, but if so, it will be clearly stated via email.

The function names in your submissions must match the names in the assignment specifications EXACTLY (if specified). If the function name does not match exactly, you may lose a significant number of points. (Double check names like "count-occurrences"! -- are there 1 or 2 c's? how about r's?)

Code Style

Please comment your code thoughtfully:

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. (Or, you can print it out and debug your code away from machines.)

I should not have to modify any of your source code to grade your submission, especially not to get it loaded into a REPL. If it breaks on loading, that's a very bad sign. If you can't get a particular function to work, please define a stub which prints a meaningful message such as "STUB: function [function-name] not implemented.".

Use local variables in your implementations where possible. Global variables should only be used for parameters and data that you intend to be accessed repeatedly by various functions. The convention for global variables in Common Lisp to enclose them in asterisks, like so, *my-global-variable*.

Unless stated otherwise in the specific problem, type check your inputs. Your function should never throw a REPL breaking error. If you don't, your functions will fail my tests!

Test File

Testing is important. It is a significant portion of the grade (~20%) and will be graded critically. Include meaningful test cases for each problem, and make your test file (*_test.lisp) executable in SBCL. A good, modular test framework for Lisp can be found in Practical Common Lisp.

The basic idea is to print, for each test case:

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, we will, and your program will probably fail with a REPL breaking Lisp error.

Writeup/README

Please include the following in your writeup:

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 Policy


Late assignments will accepted with a 10% 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. We may refuse to accept severely late assignments [ >2 days ], depending on the time required to grade the particular assignment and the quality of your excuse.

Grade Appeal


If you wish to appeal your mark on an assignment, you must do so within five weekdays of receiving your mark. No appeals will be accepted after this period. In addition, when presenting your appeal request, you must submit a written statement of why you contest your mark and which questions you'd like me to re-evaluate. Appeals will not be accepted without your written statement.

Things Related to Lisp


Practical Common Lisp Free online book. Accessible, less technical than most. Good for getting an easy intro to Lisp.

Paradigms of AI Programming (PAIP) - This book is highly recommended by Adam Purtee, a previous TA for this class. His comment from previous years:

[It's a] very nice book, worth referring to especially when trying to make a particular program work or work more efficiently. I bought a copy for this semester (2015) so that I can return the borrowed one to the library. It's still worth it. If you're into python, check out this project to translate the PAIP examples and code into python: PAIP in Python

For gritty details of specific functions, try Googling the function name + clhs, and following the top result. Ex., "rplaca clhs".

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 '/p/lisp/acl/linux/latest/alisp'.

Slime works on top of emacs and is a powerful and popular development environment for common lisp.

Here's a decent looking tutorial for emacs: absolute beginners guide to emacs.

Here's a copy of Adam Purtee's (Adam Purtee is a previous class TA) test scripts: test_framework.lisp and example testcases. Ironically, the test framework has not been thoroughly tested, so use at your own risk.

The canonical Lisp reference (a BIG book) is Common Lisp The Language, by Guy Steele. It's freely available in pdf form from CMU: link.

Maxima is a computer algebra system, which is written in Lisp and open source. It's in fedora repositories.

You might find the pattern matching and transformation program TTT useful. It's a system Adam Purtee built for Len to facilitate easy pattern based transformations of nested s-expressions in Lisp. Here is a link to the paper . To use it on the csug network type (within a lisp repl): (load "/u/cs244/ttt/src/load"). To use it on the other (phd/research) network, type: (load "/p/nl/tools/ttt/src/load"). For usage elsewhere, you can get the version that I manage from github, which supports SBCL. In any case, there is a file ttt/README with example usage. The main thing you're going to be interested in is applying a rule: (ttt:apply-rule '(/ x y) expr). That will transform every instance of y within expr to x, and return the result. x and y can be nested lists.

Having trouble printing big lists on a single line? Try turning off the pretty printer: (setq *print-pretty* nil). Still not working? Try increasing the margin: (setq *print-right-margin* 10000)