Name  : Alex Givens
E-mail: givens@wolf

Project #2: (May 22, 1991)
Domain: squaredance

Description:
I've always thought that it must be a very difficult chore for a square-dance 
caller to figure out which motions to call at a square dance.  This domain would 
allow the caller to specify a list of motions that must be used in a dance and 
then Prodigy will output a dance using all the specified motions (and possibly 
some non-specified motions) at least one time each in an acceptable order.  
Prodigy might also return failure if inconsistencies exist in the dance 
specification (e.g. requiring a partner-swapping motion in the motion list while 
requesting partners not be swapped).

Time estimate: 20 hours

Similarities and influences:
I don't think this domain is very similar to any single domain we've looked at 
in class.  My thinking has certainly been influenced by these domains regarding 
different ways to look at and represent the same problem.


Project #3: (May 29, 1991)
Time estimate: 40 hours

Questions:
1. a. The primary goal of a square dance caller is to provide a dance that is 
fun for the dancers, is as innovative as possible with motion combinations, and 
is aesthetically pleasing.  I can see no way for Prodigy to guarantee that any 
particular dance it generates is 'fun.'  This is not a short-coming of Prodigy, 
but rather a case where 'fun' is a subjective human feeling.  Prodigy can hardly 
be innovative in the way desired.  Given a fixed list of motions, Prodigy will 
produce the same dance every time.  A human caller could be expected to generate 
many different dances from this same fixed list.  Prodigy cannot remember every 
solution it has ever generated for a particular problem.  Aesthetics are another 
subjective human feeling.  Each caller will view the kaleidoscopic patterns of a 
dance differently based on their experience as a caller and many other 
intangible factors.  It might be possible to use control rules to enhance the 
aesthetic appeal of a dance, but only from the point of view of a single caller.  
A different caller would require different control rules.  The above three 
aspects basically boil down to finding the 'best' dance, where 'best' has no 
fixed absolute definition.

   b. I thought that the partner swapping aspects of square dancing would be 
difficult to model in Prodigy.  This does not seem to be the case.  I came up 
with operators to handle all four partner-swapping motions in a square dance.  
The appropriate operator fires when the 'partners' predicate needs to be 
manipulated.  I must point out that my judgement here may be premature as I do 
not have the partner-swapping aspects running 100% correctly yet.

   c. I found the 'solution' command useful- even if a problem failed because 
the node limit was exceeded, 'solution' prints out the partial solution obtained 
by Prodigy so far.

   d. The one modification I would make to Prodigy is a major rewrite of the 
manual.  The current manual seems to be sparse on information in just those 
places where I need the most help and/or explanation.
