Trevor Gulick : trevorg@wolf.cs.washington.edu

flight-scheduler

	The domain contains operators and functions which are used to
determine if the goal state is attainable from the initial state.  The initial
state must include a place or destination, an initial time, and a changeover
time which is the minimum time to allow for flight changeovers.  In addition
a time constraint and a cost constraint can be included.  The goal state must
be at a single place.  The problem solved by the elements of the domain is to 
find a series of flights from the initial place to the goal place which meets 
the changeover, cost, and time constraints.

	This domain took about 60 hours to implement, which mainly was spent
rewriting existing elements to get them to perform within the search limits.

	As far as I know my domain is unique with the possible exception of
the pathplanning domains, and I did not use any ideas from existing domains.

	I was not able to implement the best solutions to the problem, in the
sense that the best solution can be implicitly asked for or always given.  The
cost and time constraints however serve to find any solutions that meet their
constraints and thus they can be used to search for better solutions.  The 
control rules do not find the best goal always but attempt to approximate
what the best goal would be in general situations.  For a cost constraint
generally you want to take the least expensive flights, and for a time
constraint generally you want to take the earliest arriving flights.  This is
not true for all cases however, and I was unable to go beyond this.  Temporary
conditions such as weather which is always changing I was not able to
implement.  Instead the weather is given in the start state and the assumption
is made that it will remain relatively constant.  A better flight scheduler
might be more adaptive allowing for better and worse weather conditions that
could result in possibly better if not required flight changes.  There is no
uncertainty involved such as delayed flights which could not be implemented
for the same reason as the temporary weather conditions, it requires a
schedule with alternatives which gets very complicated.

	There are two aspects of my domain that I thought would be difficult to
implement but turned out otherwise.  In the beginning I started out with a
search space that was close to the combinatorial extreme almost.  It is easy
to create a domain in which the problem is solved by just doing somewhat of a
combinatorial search of the possibilities.  By moving generators around and
changing functions, I was able to come up with a domain that solved basic
problems in the optimal amount of nodes with no control rules at all.  Adding
control rules made the type and number of problems that could be handled that
much greater.  I also wanted to incorporate preferences for places with better
weather conditions than others.  This is impossible as far as I know without
using control rules.  I had to write a meta-function but it was fairly simple.

	The features of Prodigy that were the most useful were the analysis
features.  Without the optrace and opfail combination I would have been lost
several times as to what the cause of the operator failure was.  The sctrace
and scfail combination also helped with correcting control rule problems.  The 
analyze commands also let you go from node to node to collect information that
helped to design control rules as well as operator and function modifications.

	One of the most frustrating things running the problems was having
hundreds of nodes whizz by and trying to stop the screen output with the 
ctrl-S key.  There should be a step output facility which allows the output to
be displayed one node at a time or a screen at a time so that the user would 
not have to deal with the impossibility of controlling the output with the
function keys.  While the analyze facility can be used to go around and look at
nodes it is not the same as being able to view them in progress as they are
created by the problem solver.


