Douglas "Tad" Orman
CS473 
email: tadorman@wolf
       c473bv@coco

DOMAIN NAME: CS Course Scheduling VERSION 1.0            (cs-sched)

Version Summary:

1.0 -  Goal is to find a complete CS schedule that meets the credit
       requirements by the department.  Domain can only solve small
       problems due to a problem Prodigy can not deal with well. 
       See "FATAL" below for more info.

2.0 -  We abandon trying to meet credit requirements altogether and 
       simply find a schedule for classes that the student wishes to
       take.  The domain does calculate credit totals so that a higher
       level interface can use it for further study.

       ie. The goal state will contain a host of predicates of classes to
       schedule.. ie (Scheduled-class CS473)... This eliminates the problem
       discussed below under "FATAL".

NOTE:  Although 2.0 doesn't suffer from "FATAL", I do not find this
  domain to be as interesting as the first.  This version was "whipped
  up" and tested in a few hours JUST to get a domain that could work
  on larger problems.

  The following discussion pertains to the original version, which I spent
  an enormous amount of time working on.. the version I found most 
  interesting in that it was challenging for Prodigy in terms of 
  credit counting / subgoaling with scheduling on the side.


PROJECT QUESTIONS:

(a) What aspects of your real-world problem were you NOT able to model
    in Prodigy?

I was able to successfully model EVERY aspect that I set out to model.
The domain:

	Schedules classes in the quarters specified in the initial state.
	Limits the number of classes taken per quarter as specified
		in the initial state
	Resolves scheduling conflicts with other classes scheduled
		in the same quarter
	Resolves conflicts with taking other "suicide" courses in
		the same quarter.
	Ensures that the number of credits required to satisfy
		core requirements is met (version 1.0).

I was UNSUCCESSFUL, however, in getting Prodigy to model my domain
on a real world problem due to a "FATAL" domain characteristic.
(see FATAL).  The domain can run successfully on VERY simple
domain problems which are provided.

FATAL:
 
There is one "serious" problem with this domain in which Prodigy offers
little help in resolving.  The domain works by trying to acheive a certain
number of credits taken.  Scheduling classes is achieved as a side
effect to acheiving the credit goals.  The major flaw occurs subgoaling
on the credits which leads to an enormous explosion not easily
handled by Prodigy.  This is demonstrated by the following trace.

 N1 (DONE)
 Alts: *FINISH*

   N2 (SCHEDULECOMPLETE)
   Alts: INFER-SCHEDULE-COMPLETE

      N3 (INNERCORECOMPLETED)
      Alts: ADD-INNERCORE-COMPLETED

LOOK AT THIS!!!
  |
  |      N4 (INNERCORE-CREDITS 15)
  ---->  Alts: ADD-INNERCORE-CLASS CS326 <QUARTER> <YEAR> [2-3]
  |
  |         N5 (INNERCORE-CREDITS 10)
  ------>   Alts: ADD-INNERCORE-CLASS CS326 <QUARTER> <YEAR> [2-3]
  |
  |            N6 (INNERCORE-CREDITS 5)
  --------->   Alts: ADD-INNERCORE-CLASS CS326 1 1991 [2-6]

            ...Done: ADD-INNERCORE-CLASS CS326 1 1991


THE SUCKER TRIES TO SUCCESSIVLY SCHEDULE THE SAME CLASS!!


            N7  . . .
            There are no relevant alts for this node!
-------------------------------------------------


So, it is painfully obvious why this domain, with this behavior
is not practical. 

The problem is that as the tree expands downward (subgoaling), the
children have no idea what was attempted in the bindings above as
the state doesn't actually change until an operator is *applied*.
Since we subgoal many times to shave down the total credits needed,
none of the operators are actually applied until the last operator
in the chain achieves the credit goal.  As we trace back up the tree
to acheive the other operators we THEN find that the bindings have
already been achieved.. leading to a combinatorial blowup in
backtracking based on the number of classes.

This lack of knowledge at children nodes also prevents other
good SCRs from being implemented to further cut the trace.

The goal stack provides us only with information pertaining to 
subgoaling on credits.. no scheduling information.

A suggestion was to break the operator that subgoals into two pieces.
The original does virtually the same thing with the exception that,
having picked a class and resolving conflicts, it subgoals to add
the class to the state BEFORE continuing to subgoal updating and
achieving the credit totals.  This way the class is updated in the
state and can be checked via SCRs as we subgoal.  

It subgoals calling a class specific operator to add itself to the state.

(ADD-CS321
 (PRECONDS (~ (Scheduled-class CS321)))
 (EFFECTS  ((ADD (Scheduled-class CS321)))))

The search control rule to reject the binding is:

(REJECT-CLASS-ALREADY-SCHEDULED
 (LHS (AND (CURRENT-NODE       <node>)
           (CURRENT-OP         <node> ADD-INNERCORE-CLASS)
           (CANDIDATE-BINDINGS <node> (<class> <quarter> <year>))
	   (KNOWN              <node> (Scheduled-class <class>))))
 (RHS (REJECT BINDINGS (<class> <quarter> <year>))))

In theory, things look great!  What follows is a trace of what actually
happens when this rule is implemented.

 N1 (DONE)
 Alts: *FINISH*

   N2 (SCHEDULECOMPLETE)
   Alts: INFER-SCHEDULE-COMPLETE

      N3 (INNERCORECOMPLETED)
      Alts: ADD-INNERCORE-COMPLETED

         N4 (INNERCORE-CREDITS 15)
         Alts: ADD-INNERCORE-CLASS CS322 1 1991 [2]

            N5 (SCHEDULED-CLASS CS322)
            Alts: ADD-CS322

         ...Done: ADD-CS322

Yes!  It found a valid class and subgoals to add it to the state.

         N6 (INNERCORE-CREDITS 15)
         There are no relevant alts for this node!
-------------------------------------------------

Notice here that after it correctly adds the class to the schedule
that it returns NOT to node N4 to continue and resolve the credit
counts.  Instead, creates a NEW node N6 in which it retries ALL
the preconditions AND applies the SCR.  The SCR rejects the binding of a
class already in the state... So the SCR is used prematurely.  The
operator clobbers itself subgoaling on the precondition to add the
class to the state.

The other solution is to right a control rule using a meta function
that can examine bindings up in the tree for prior nodes.  Search
up, examine each node and it's CURRENT-BINDINGS.  This rule
requires knowledge of Prodigy and it's internals that are well 
beyond my resourses.  The function would be a major undertaking.

I hope that you understand that this so called "easy" domain is by no means
easy for Prodigy to solve... particularly since I've disabled the variable
credit option (forcing credit increments of 5 so that totals divide evenly)
which would otherwise blow the thing further.

QUESTION: Was the language expressive enough... ?  NO!  I need 
  some search control meta functions to allow me to check earlier
  nodes for their bindings.  It would be nice to have a bigger
  stock of standard meta functions.


(b) What aspects of your problem did you think would be difficult
    to build in to Prodigy, but turned out to be easy... etc.?

I found that this domain was conciderably harder to build with the
resources provided as I spent an ENORMOUS amount of time trying
to overcome the FATAL aspect of this domain.  I worked very hard
to get credit resolution working alongside the scheduling (so they
don't bomb each other) AND then to try to limit the amount of 
backtracking involved.  Version 2.0 was conciderably easier to 
implement, but not as interesting.


(c) What features of Prodigy were particularly useful?

I found the "advise" feature most helpful as it allowed me to 
see in great detail all the ALTS that Prodigy was concidering.

The online help was pretty good as well although I felt that I had to 
hit a few too many keys, searching sub-menus.


(d) If you could make one modification / addition to Prodigy,
    what would it be?

I would like to see a feature that dumps text traces out to a user
specified file so we don't have to see it scroll on, tying up the
terminal. It might be faster AND easier for review.

(other suggestions):

I would like to see MUCH BETTER DOCUMENTATION!!!  HOW ABOUT 
COMMENTING THE SAMPLE DOMAINS SO WE STUPID PEOPLE CAN UNDERSTAND
WHAT IS GOING ON!

How about my meta function to grab bindings for nodes higher up
in the search tree?














