Courses", $CS_COURSES_ROOT_URL); ?>
General Instructions"); ?>

Homework exercises are absolutely key to comprehension of the course material. Important qualities of the structure of computer programs are determined, not just by mental contemplation of the programs, but by the detailed logistical efforts required to make them work. You can only begin to understand those logistical efforts by making some of them for yourself.

Homework exercises are also key to my evaluation of your work. It is impossible to receive a satisfactory grade in this course without performing well on the homeworks.

All homework assignments must be submitted using the handin command before 11:59 PM on the due date.

If illness or personal/family difficulties delay your work, let me know as soon as possible and we can make special arrangements. A moderate amount of trouble with the computer systems is a normal part of computing, and you must budget time for it. I will give extensions only for massive computer failures, e.g. all CS Linux systems out of commission for a whole day.

I have a bimodal attitude toward lateness, modelled by mathematical catastrophe theory. As long as lateness isn't causing logistical problems for the class, I don't pay much attention to small (i.e. minutes or an hour) lateness. If lateness starts causing logistical problems, I turn into a terrible rigid authoritarian. In particular, I may decide to close assignments at the due minute by disabling the handin command.

Getting to the handin command"); ?>

The handin command is only available on the CS Department's GNU/Linux hosts, and will not work at other locations even if copied there. The command is stored at ~odonnell/Teaching/Utilities/handin.

To avoid typing that long sequence each time you use it, you may add ~odonnell/Teaching/Utilities to your execution path, $PATH. $PATH is a shell environment variable containing a sequence of locations to search for executable commands, separated by colons (:). To find out the contents of your $PATH, type echo $PATH. To add my command directory to it, type export PATH="${PATH}:~odonnell/Teaching/Utilities".

To avoid resetting your $PATH every time you start an interactive shell, you may add export PATH=${PATH}:~odonnell/Teaching/Utilities to the end of a file named .bashrc in your home directory, or you can modify a path assignment that's already there, e.g. to export PATH="$HOME/bin:$PATH:.:~odonnell/Teaching/Utilities".

Using the handin command1"); ?>

To hand in your work on a particular assignment:

  1. Use cd to enter a directory containing your work.

  2. Type handin n file1 file2 ... where n is the number of the assignment, and file1, file2, .. are all the files containing the work that you wish to hand in.

handin will warn you if the assignment number is invalid, or if one or more of the files doesn't exist, or isn't a regular file. The files that you hand in are stored only by their base names (the part after the rightmost "/", if there is one), not by their paths. handin will not warn you if you submit several files with the same base names, and only the first one will get through the handin properly. I'll try to create a warning in an upgrade of handin.

If you mistype some of the file names, handin will still put in the good ones. But you should resubmit with all of the files, not just the ones that missed the first time.

You may resubmit as many times as you like, up until the assignment deadline. I normally only look at the last submission, but I save them all in case we have to unwind from a problem.

  1. One or more files of definitions, saved from the definitions window in DrScheme. Each one must have a sensible name (sometimes specified by the assignment), ending in ".scm". Each one must have a block of comments at the top with your name shown prominently.

  2. One or more files of test cases. In the early assignments, these will be test suites saved from the test suite window in DrScheme. We may switch to a different technique for using test cases in later assignments.

  3. Possibly one or more explanatory text files. Some explanation can go in the definitions files in the form of comments, but later assignments will probably require some explanations that are too long or delicately formatted to fit nicely in Scheme comments. Explanatory text files may be in a number of formats, including:

    1. Plain text (sometimes called "ASCII"), in a file ending in ".txt". Plain text must be broken into lines of a pleasant length: 70 characters is OK. The line breaks must be in the form used in Unix and Linux systems, which is different from Windows and Macintosh. You may use your favorite text editor to compose text files, translating the line breaks if necessary. If you don't have a favorite editor, try emacs or xemacs on a GNU/Linux system. I think you can use DrScheme to edit text, but it's not a particularly good text editor for future use..

    2. PostScript, in a file ending in ".ps". Lots of word processors export PostScript. You can also produce PostScript with the TeX typesetting system.

    3. PDF, in a file ending in ".pdf".

    4. DVI, in a file ending in ".dvi". DVI is the device-independent output of the TeX typesetting system.

    5. Standard HTML, in a file ending in ".html". The buttons on the bottom of class Web pages provide a way to test whether your HTML satisfies the standard. I use a variety of Web browsers, but they all display standard HTML. I will not read nonstandard HTML files, and the fact that they work on Netscape or Internet Explorer is irrelevant to me.

    I may agree to other formats if you clear them in advance. I will not agree to secret proprietary formats, such as Word.

    Plain text is acceptable for all explanatory files. The readability of the presentation will affect my comprehension, and therefore your grade. I award extra points for particularly clear and informative presentations.

All homework will be judged (except assignment #0), not as mere evidence that you have written and executed certain programs, but as an insightful presentation of interesting ideas, using programs and their executions as part of the presentation.

It is your responsibility to execute your programs on sensible test cases that demonstrate their interesting qualities. In most of the homeworks for this course, the number of test cases should be very small. Look for the 2 to 5 examples that illustrate the appropriate concepts clearly. The choice of examples may depend on the way you have written your programs, as well as on the problem that you are solving. Strive for concise clarity, not volume or cuteness. We will discuss test cases in class as we go along.

Assignments will be posted here as they becomes available. See last year's homework page", "http://www.classes.cs.uchicago.edu/classes/archive/2002/fall/12500-1/Homework/"); ?> to view Autumn 2002 assignments.

I cooked up a graphical interface for a really bad calculator. All it can do is add two numbers, mainly because it can't parse any other sort of expression. When you've finished Assignment #3, you can cut and paste your much better parser into my code, and you'll have a pretty boring but not quite so bad calculator, that can evaluate any expression involving +, -, *, /, ^. Even though you have solved the problem of parsing applications of the fib, the evaluation mechanism in the calculator doesn't know how to evaluate it.

As the quarter progresses, I will fix up the graphical interface a bit, and you will put a much more powerful sort of evaluation into it. For now, if you really want to look at it, you'll find the code below.

Last modified: Thu Oct 23 18:55:47 CDT 2003