Laboratory Exercises

CSC 261 - Artificial Intelligence - Weinman

Information about expectations for laboratory exercises and methods for preparing to submit them.


This course features weekly laboratory exercises, as listed on the course schedule.
Unless otherwise stated: Programs (source code, compilation, and output) are to be submitted in the format below.

Submitting laboratory exercises

In turning in any programs for the course, please follow these directions.
  1. The first seven or more lines of any program should be comments containing your name, your mailbox number, your lab section, an identification of assignment being solved, and a description of the contents of the file. For example:
    ;; File
    ;;   search.scm
    ;; Author
    ;;   Jerod Weinman
    ;;   Box - Noyce Science Division Office
    ;;   CSC261.01
    ;; Summary
    ;;   Provides a collection of routines finding solutions to search space problem
    ;; Provides
    ;;   (search start-state problem enqueue heuristic)
    ;;   (breadth-first-search start-state problem)
    ;;   (depth-first-search start-state problem)
    ;;   (uniform-cost-search start-state problem)
  2. A comment is required for every definition of a Scheme procedure or C function, stating the purpose of the program unit in English. While complete 6-P documentation is not required for every method, it embodies many good practices you may wish to consider. Documenting before you write a procedure can help you plan and clarify the requirements of your implementation.
  3. Obtain a nicely formatted PDF listing of your source code using the enscript(1) command:
    enscript -p - -Ec -2 -r --color  source.c ...  |  ps2pdf - prettysource.pdf
    for C or
    enscript -p - -Escheme -2 -r --color  source.scm ...  |  ps2pdf - prettysource.pdf
    where prettysource.pdf is the name of the file in which you want the formatted source code stored (enscript generates a PostScript file, which you will pipe to ps2pdf(1) for conversion to PDF.) If your work involves several program files, list the primary program first, then list any supplementary files. Multiple source files can be placed in one call to enscript. While you may also use a wildcard such as *.c be sure this includes the files requested for the particular assignment.
  4. As appropriate, create a transcript of your program's compilation and output runs using the script(1) command:
    1. In a terminal window, start recording output to a file called transcript with the command:
      script transcript
    2. If programming in C, compile your program with gcc or make as appropriate.
    3. Run your program with appropriate test cases to verify its correctness. It is usually best if you have written one Scheme file or script to take care of most of this behavior. For instance:
      mzscheme -l lang/ -f driver.scm
      runs driver.scm with the "Pretty Big" version of Scheme we'll use in DrRacket.
    4. When your runs are complete, stop the script session by typing Ctrl-D.
    5. Convert the recorded text file to a nice, printable PDF file using enscript(1):
      enscript -p - -2 -r  transcript  |  ps2pdf - transcript.pdf
      where transcript is the name of the recording file you created above, and the .pdf file is the printable version enscript(1) creates.
  5. Concatenate (merge) your program source, transcript, and report etc. For example,
    pdfconcat -o submission.pdf prettysource.pdf transcript.pdf
  6. If the assignment requires a PDF and source files, create an archive of your source files and PDF for electronic submission. For example,
    tar cf submission.tar submission.pdf source.c ...
    where submission.tar is the name of the archive file you want your files stored in. You may list as many source files on the line as you wish, or even use a wildcard (*.c) Please be sure you do not include any intermediate PDF files or urequested source files.
  7. One group member should submit an electronic version of the archive (submission.tar from above, or submission.pdf if no source files are required) online via PioneerWeb by the due date. Be sure you allow enough time to construct your submission before the deadline.

Notes on grading


Because every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in Scheme):
  (if (or (not (commented? code))
            (not (visibly-tested? code)))
        (grade code))
When a program is submitted according to the format specified above, it should be understood that the transcript reflects a complete session of program listing, compilation (when applicable), and running. With this understanding, editing of any script file is strictly forbidden and will result in automatic failure on the assignment. Such editing also may raise questions of academic dishonesty; and, by College policy, any evidence of academic dishonesty must be turned over to the Committee on Academic Standing for action.


Because code maintainability is an important part of development, your labs will be graded in part on style, as well as correctness. After all, if I cannot understand your code (or it takes me too long to), I cannot give it a grade regarding its correctness.
Some style matters I care about: Failure to incorporate these style considerations will lower your grade.


Adapted from Assignments for Computer Science 213, Henry Walker; and CSC213, Fall 2006 : Laboratory exercises, Janet Davis. Some of the style considerations were adapted from Marge Coahran's.