Laboratory Exercises

CSC 261 - Artificial Intelligence - Weinman

Summary:

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

Overview

• Collaboration with students outside your group is NOT allowed on laboratory exercises.
• You may use language references to determine relevant Scheme or C syntax and semantics. Because syntax is standardized, we will consider syntax and semantics to be general knowledge, and you need not cite reference sources for these purposes.
• You may consult only the textbook, course web page, and lab assignments for information regarding algorithms. However, any non-syntax consultations (including the textbook and language references) require formal citation within the related program or exercise.
• You always may consult the instructor and mentor regarding questions on labs or assignments.
• You may always consult your colleagues regarding questions on interpreting assignment-related example/starter code or about what an assignment is asking. However, you may never consult with non-group members about solutions or implementations.

Submitting laboratory exercises

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/plt-pretty-big-text.ss -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

Requirements

  (if (or (not (commented? code))

            (not (visibly-tested? code)))

        0

        (grade code))

Style

• Indentation and whitespace that help delineate code blocks. (Most editors will help you with this.)
• Helpful comments on blocks of code or particularly complicated expressions
• Functions that are reasonably small. A very good guideline I try to follow is getting an entire procedure to fit on much less than one screen; this makes interpreting a function's action more readable by forcing you to break it down into named steps that can be seen at once. It also promotes easier debugging and unit testing.
• Code lines that are no wider than 80 characters. This makes them easier to read both on screen and on paper. (Note: If running enscript on your program code produces X lines were wrapped, where X is some number, then your lines are wider than 80 characters and you should re-format your code with additional linebreaks.)

Acknowledgments