CS 244/444:
Logical Foundations of
Artificial Intelligence
Fall 2009
Instructor:
Prof. Lenhart
Schubert
See his class
page.
TA:
Jonathan Gordon
‹jgordon@cs.rochester.edu›
Office hours: Friday 10:00–12:00 (in CSB 630)
News
- You can now check the low, median, mean, and high for the assignments here.
- Lisp tutorial is Wednesday, 2009-09-09, at 8:00 pm in CSB 632.
- Major updates to this page and class news will be noted here.
Office hours are a guaranteed time when you can see me in my office and ask questions about the class material. If you want to ask at a different time, you can email me your question or a request to meet by appointment.
Homework
Note: Late homework will be accepted but will lose 10% credit per day (counted as 24 hours from the day/time it was originally due). Saturday and Sunday count as one day.
To turn in late homework without penalty, you must have permission from the instructor.
Written Assignments
- Written assignments must be left in my mailbox in the Computer Science mailroom (CSB 727) before the stated time, which is usually at 5:00 pm. Bear in mind that the room is usually locked after 5.
- I suggest you type all written assignments (ideally using LaTeX). Handwritten work can be turned in, but it must be written legibly. If you are going to type your work, plan ahead – typesetting the answers can take a while.
Programming Assignments
- All programming assignments should be turned in via the provided
script:
- Grads:
/u/cs444/TURN_IN dir - Undergrads:
/u/cs244/TURN_IN dir
If you cannot use the script,
zip(ortarthengzip) your files and email them to me. - Grads:
- Programing assignment submissions must include the following files:
- README: A write-up for the assignment.
- your-CS-id_src.lisp: The source file containing all necessary code for your solutions.
- your-CS-id_test.lisp: A source file containing test cases demonstrating the correctness of your code.
- The write-up should give the names and a description of the arguments for the functions I need to call to test your program, a general description of the algorithm used including design decisions (e.g., using a hash table instead of a list), known bugs, and answers to any questions asked in the assignment.
- All functions must conform to the specifications given in the assignment – function names must be the same, as should input and output values. If you want to use a different data structure than specified, you should make functions that convert to/from the standard format.
- Programming assignments should demonstrate good coding style and commenting. See below for a partial description of what this entails.
- You should explain what the test cases in your test file are showing and you should include enough test cases to satisfy yourself and me that your code works correctly. Always check unusual cases: Negative numbers, empty lists, wrong arguments, etc.
Grading Breakdown
Approximately:
- 60% functionality
- 20% coding style
- 20% documentation and testing
On Programming
Comments
“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. Good code needs fewer comments than bad code.”
— Brian W. Kernighan and Rob Pike,
The Practice of Programming
You must comment your code. It is unlikely that you, two days after you write the code, will know what you were thinking when you wrote it. It is much less likely that I will have any idea what you were thinking.
However, needless comments of the type
;; Print the current value of x (format t "~A" x)
should make you ashamed.
Explain big decisions and anything that would be unclear to a competant Lisp programmer looking at your code. If any part of your code is so confusing that it requires extensive comments, rewrite the code.
Naming
Choose the shortest names for variables and functions that clearly express what they are. Follow Lisp conventions such as the use of asterisks around global variable names or suffixing “p” to predicate names.
Lisp Style
Just because the language provides it doesn’t mean it’s a good idea:
- I recommend avoiding the general loop operator
do– usedolist,dotimes,mapcar, or recursion instead. - Avoid
progn. If you’re tempted to use it insideif, usecond(when you have two or more branches) orwhen(when you have a single branch) instead. - Avoid
prog,go, andtagbody. They will lead you into confusion and bugs.
Indent your code consistently. Lisp is a language with fairly standard indenting practices – look at how Emacs autoformats the code or see the examples in Common Lisp: The Language. Do not use tabs as the interpretation of their width varies – your code may be rendered illegible to others.
Always ask yourself what the clearest, most elegant solution would be:
If you’re nesting if statements deeply, use a
cond instead! If your function is doing several conceptually
distinct operations, split it into multiple functions.
Your code should not contain more than 80 characters per line.
Learning and Using Common Lisp
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.
Online:
- Guide: Practical Common Lisp. Recommended reading: Chapters 1, 2, 5, 6, 10, 11, 12, and 22.
- Reference: Common Lisp: the Language, 2nd ed., by Guy L. Steele Jr. Print copies are in the graduate software lab.
In print:
- Paul Graham: ANSI Common Lisp
- Peter Norvig: Paradigms of AI Programming: Case Studies in Common Lisp
Additionally, Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman uses the closely related Scheme language and is a great text about programming.
Emacs
Unless you are very attached to another text editor, you will find that
using Emacs to write and debug Lisp will make your life
easier. In particular, you should use SLIME, which is a Lisp-editing
mode that is installed on the URCS grad. systems in
/usr/grads/share/emacs/site-lisp/
I add to my Emacs configuration file (~/.emacs):
(add-to-list 'load-path
"/usr/grads/share/emacs/site-lisp/slime/")
(setq inferior-lisp-program "/usr/staff/bin/alisp")
(require 'slime-autoloads)
(eval-after-load "slime"
'(progn
(slime-setup '(slime-fancy))
(setq slime-complete-symbol*-fancy t)))
Undergrads should change the first line to contain
"/u/cs244/share/slime" as the path.
To start a SLIME session, type M-x slime (where M is the
“meta” key – usually escape). To exit this interactive
session, type , quit.
You can also read what Ben Van Durme wrote about Emacs and Lisp though a few details about the local SLIME installation are out of date.
Debugging
See Myros’s write-up.