Domain Name: Campaign
E-Mail address: priebe@wolf
Name: David Priebe

	The biggest thing that I couldn't represent in prodigy was an actively campaigning 
opponent.  I would have had a very hard time getting prodigy to do a minimax search, or anything
like that.  I also had a hard time dealing with representing geography.  I wanted to represent 
geography and thus give greater depth to the air travle and driving aspects of the domain.  I
couldn't, however, come up with any real way to represent geography in my domain that wouldn't 
explode the state beyond the point of reason.  It also would have made it much more difficult to 
represent the drive operator, because the direction travled becomes important, and the locations
travled through could also become significant.  In the end I had to settle for differentiating 
simply between those locations reachable by car, and those not (a significant lowering of sights
if you ask me).  Another difficult thing to modle was the unpredictability of people.  How in the
heck would you do a random in prodigy?  The finaly really painful thing for me, was not being able
to convieniently represent a time-dependant thing like TV commercials.  It is difficult to 
continually represent the votes gained, and lost, by such a medium.

	I never did find the clever ways of encoding my domain.  Most of the time I ended up 
getting stuck behind a lack of complete understanding as to exactly how prodigy worked and 
had to wade through a mass of traces just to figure out that I was thinking about something the 
wrong way.  I still don't have the nack of thinking like prodigy, and so nothing has turned out 
to be particularly simple (hey, I never was much of a hacker).

	The aspects of prodigy that I came to like were the debugging facilities, especially
analyze.  These became the most useful tool for my learning something of the way prodigy thinks
about the operators given it.  The main problem is that it is a switch from the way I am used to 
thinking about such problems.  The ability to see what is going on in the state at any one moment
was another one of the great feature of prodigy.  It was very useful (and kinda fun on the rare 
occasions when things worked).  Probably the best programming feature is the way the bindings work.
You can come up with some interesting, and unforseen, solutions to some problems just by playing 
with the way prodigy binds some of the variables.  One example was the elimination of the 
greater-than call in my Has-Won inference rule.  Once it became clear that all that was really 
necessary to get prodigy to subgoal on TOTAL-VOTES was to bind the initial value to the value
of the minimum number of votes needed to win.  Prodigy would then, quite pleasantly, take care of
the rest.

	The one addition I would make is a toss-up between a macro facility and decent arithmetic
operators.  The arithmetic entices me because it strikes me as rather rediculous to have to 
write large ammounts of lisp code just to add, subtract, or multiply two values, and bind them
to a variable.  I currently have 13 lisp functions that do addition, subtraction and multiplication
for my domain (I hope to cut that to ten, but I think it might grow again, since the multiplication
doesn't work yet).  The reason I would like to see a macro facility is that I noticed a disturbing
tendancy to write large quantities of redundant code, and then end up debugging those large 
quantities of redundant code for the same errors.  This little tendancy happened to eat up large
portions of my time, and enthusiasm.  Both of which I need to write good programs (a set in which
this is not yet a member).  I needed to change the vote counts in every operator, and I was having
trouble getting the incrimentors to work.  Having no clear idea how to procede, I began going with
trial and error, the problem is, this involves a lot of editing, a lot more than should have been
necessary by the time all was said and done.