- Homework 2 Due this Friday!
- The Brain viewing #4 -- Thursday 2/23, 5pm, room 209. (I missed the announcement on the last one...)
- Written Grading Scheme update! Please take a look.
- Homework 1 graded and handed back. Please see me in office hours if you have not gotten yours back yet.
- The Brain viewing #2 -- Thursday 2/8, 5pm, room 209. With pizza and beverages!
- HW 1 due today at 5pm. Please submit a hard copy in my mailbox in room 727.
- Lisp Intro Tutorial -- Monday 2/3, 6pm, room 727 (through the mailroom). Please bring your laptop if possible!
- The Brain viewing #1 -- Thursday 2/2, 5pm, room 209. With Pizza!
- Lisp 1 clarifications
- The website it finally up! Please read through everything and let me know if you have any questions.
All written assignments must be turned in before the deadline. They can be put into Gene's mailbox (in the CS mailroom - CSB 727), in person (before class or in office hours), or via email (please include the class name, your name, and assignment name in the email so it doesn't get lost). Beware: the mailroom is locked after 5:00pm -- if you are unable to get in, you may slip it under the door of my office (CSB 615).
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 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 CreditThe 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 likely 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.
You will submit one tarball via email to both TAs (see emails at the top of the page). The tarball will consist of the following three files:
the source file containing all the code necessary for your solutions to the assignment;
the test file containing your test strategies and test cases to demonstrate the correctness of your code;
the writeup for the assignment.
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
Generally, code functionality accounts for about 60%; your test file, writeup, and coding style account for about 40% 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 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?)
Please comment your code thoughtfully:
At the beginning of each function, provide a 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.
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. Global variables are dangerous as they may be rewritten where you don't expect.
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!
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 one of the Common Lisp implementations on the URCS servers (preferably 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:
- the function and input being tested,
- the expected result,
- an indication of whether the test case passed or failed, and
- the actual result.
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.
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 we 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; (In general, if you think I may have trouble understanding any part of the code, and the necessary explanations are inappropriate or beyond the scope of function or inline comments, then those explanations should be included in the README.)
the input and output data format;
which CL implementation you used
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 version.
The level of detail of the write up should be proportional to the complexity of the code. Don't feel like you have to write a 200 word narrative about a function which sorts or reverses a list, save that effort for your writeup for bigger challenges like writing pattern matching systems, symbolic calculus, etc. Sometimes a function is just easy and simple -- no need to complicate things.
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 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.
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".
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 '/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"). In either 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)