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)
Domain: sd-working
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.


Project #4: (June 3, 1991)
Domain: sq-final
Time estimate: 30 hours

Explanation:
1. I will state right up front that this final version does not work.  It 
certainly is not from lack of effort though.  In this directory there is a 
trace file called trace.sd.  Notice that at node 10 of that trace the 
problem is actually solved but Prodigy fails to notice.  I cannot explain 
this.

2. There is another file ("/sq-final/probs/sd9x.description") that describes 
the ten problems (sd90 - sd99) I have generated for the squaredance domain.

3. You might have noticed that I removed all the partner swapping aspects of
the domain.  I arrived at this decision after a discussion with my friend
who is something of an expert on squaredancing.  He claimed that it is not
really important where the partners end up at the end of a dance.  The appeal
of a squaredance is in the combinations of the motions themselves, not
whether you end up back where you started.



