Name:	Aaron Stavens (8831487)
	stavens@u.washington.edu

Domain: Course Scheduling

Description:	This domain should allow the scheduling of courses.  There are
		three kinds of goals.  Simple one course requirments, sets of
		courses, and credits from sets of courses.

Hours:		~29 hours

This domain uses binding-list from schedworld.

****** Project 3 ***********

1.
   a) Course scheduling, in particular CS course scheduling, is subject to
      a certain amount of uncertainty.  That is, you don't know when courses
      will be offered in the future.  Your only guide is the past.  To get
      a final schedule put together you must know what will be offered in the
      future.  Since Prodigy does not know how to tell the future, it can
      only give an answer based on what it has been told.

      There are a myriad of special case conditions and requirements which
      may apply to a class.  Not all of these are easy to represent as the
      domain stands now.  For instance, there is no way to represent
      interchangeable classes.  That is to say, either of two or more classes
      will satisfy a given requirement.  Also, say you have credit for some
      class, but you never taken that class.  Because of the way the
      domain is structured, it will have difficulty with that class if
      it is a prerequisite.

      Furthermore, the domain has no concept of class level (i.e. Freshman,
      Sophomore, etc. . .).  This is because of the slot filling method
      it uses to schedule classes.  At each state, the class level would
      have to be recomputed for each quarter because it could have changed
      at any point in the time line.

      Finally, the domain produces far from optimal results.  I just
      produces a schedule that satifies the requirements.

   b) Sorry, I didn't come up with any clever ways of encoding my domain.
      It turned out that things I thought should be easy didn't turn out
      to be as easy as I had thought they should be.

   c) Being able to turn the trace on and off was useful.  When the trace
      was useless, I wasn't forced to view it.  And the trace itself was
      useful for debugging.
      
   d) I'd give it a a more detailed tracing facility.   The current level
      of detail is good for tracking down the bigger problem, but I didn't
      find any way of tracking down the particular precondition that failed
      short of hand simulation.  So, if there was some way to invoke an even
      finer level of detail some hand-simulation would be could be avoided.

      One other thing which I don't think is quite what you meant by your 
      question, but I'd like to mention it anyway, is the documenation on
      Prodigy.  It's pretty minimal.  One has to do a lot of searching around
      in example files to figures out how certain things work, such as binding
      lists.  These things should be spelled out better in the manual.

Unimplemented Search Control Rules:

      I can see a need for a search control rule which would reject all
      bindings for <quarter> and <year> in TAKE which occured before or
      at the same time as the first offering of the prerequisite classes and
      all the prerequisites of the prerequisites and so on.

      Another useful search control would stop terminate the current path
      when it detected that a prerequisite for course had already been
      scheduled so that course was not offered at any later date and thus
      could not be scheduled successfully.

      I can see a need for a search control rule which would reject all
      goals (TAKE <course> <quarter> <year> <credits>) where taking
      <course> is already a subgoal.

