Homework Submission
CSC 261 |
Artificial Intelligence |
Spring 2009 |
Overview
This course features several homework assignments, as listed on
the assignments page.
-
Unless otherwise stated:
- collaboration IS NOT allowed on programming assignments.
-
you may use language references to determine relevant Scheme
syntax and semantics. Since Scheme syntax is standardized, we
will consider this to be "general knowledge", and you need not
cite reference sources.
-
you may consult only the textbook and
a Scheme Programming
Language reference for information. All non-syntax
consultations (including the textbook and Scheme references)
require formal citation within the related program or
exercise.
-
You always may consult the instructor regarding questions on labs
or assignments (at least if the instructor is in his office with
the door open).
-
You may always consult your colleagues regarding questions on
interpreting assignment-related example/starter code or about what
an assignment is asking (but not about solutions or
implementations).
-
Programs (source code and output) are to be
submitted in the format below.
Submitting Programs
In turning in any programs for the course, please follow these
directions:
-
The first seven or more lines of any Scheme file should be
comments containing your name, your mailbox number, the class 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)
;; (a-star-search start-state problem heuristic)
-
A comment is required for every definition of a Scheme method,
stating in English what that program unit is supposed to
do. Complete 6-P documentation is not necessary for
every method (unless specified otherwise), but it is
encouraged, especially on major routines. Documenting before you
write a procedure can help you plan and clarify the requirements
of your implementation.
-
Obtain a nicely formatted listing of your source code.
Create a pretty and printable file using
the enscript(1) command:
enscript -Escheme -2 -r --color -p prettysource.ps source.scm ...
where prettysource.ps is the name of the file
in which you want the formatted source code stored
(enscript(1) generates a PostScript file, hence the
".ps" extension.) If your work involves several Scheme files,
list the primary program first, then list any supplementary
files. Multiple source files can be placed in one call
to enscript(1). You may also use a wildcard such
as *.scm.
-
If you have multiple Scheme source files, create an archive of them for
electronic submission. For example,
tar cf sources.tar source.scm ...
where sources.tar
is the name of the archive
file you want your program source files stored in. You may list as
many source files on line as you wish, or even use a wildcard
(*.scm) You may also add an entire directory to an
archive by including the directory name without a trailing
"/" in the list of files. If you do this to include the entire
directory, please be sure you do not include any class files, etc.
-
As appropriate, create a transcript of your program's output runs
using the script(1) command:
-
In a terminal window, start recording output to a file
called transcript with the command:
script transcript
-
Run your program with appropriate test cases to check its
correctness (it is usually best if you have written one function to
take care of most of this behavior).
-
When your runs are complete, stop the script
session by typing Ctrl-D.
-
Convert the recorded text file to a nice, printable
PostScript file using enscript(1):
enscript -2 -r -p transcript.ps transcript
where transcript is the name of the recording file
you created above, and the ".ps" file is the printable
version enscript(1) creates.
-
Concatenate and print your program listing and transcript, i.e.,
cat prettysource.ps transcript.ps | lpr -Pprinter
where printer is the name of the printer you want
to send the output to.
-
When requested, include a separate statement that argues why
your program is correct, based upon the evidence from your test
runs.
You may use a word processor to format such statements, or you
may use a simple text file. You may easily incorporate a text
file into your submission by including it in the
transcript. Between 4.c and 4.d,
cat statement.txt
-
One group member should submit:
-
your printed work at the beginning of class on the day it is
due, AND
-
an electronic version of the source file archive
(source.tar from 4 above) online via
PioneerWeb by the beginning of class.
The late policy applies to both portions of the submission jointly
(e.g., if one portion is late both are considered late.)
Notes on Grading
Requirements
Since 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 format):
(if (or (not (commented? code))
(not (visibly-tested? code))
(not (correctness-commentary? code)))
0
(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, 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 Academic Standing Committee
for action.
Style
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 that you may want to consider:
-
Indentation/whitespace that helps delineate code blocks. (Most
editors will help you with this.)
-
Helpful comments on blocks of code or particularly complicated
expressions
-
Procedures 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 procedure'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.