Sean T. Lamont
zeno@cac.washington.edu
zeno@genetics.washington.edu
c473am@ms.washington.edu


				FARMWORLD:

		Agricultural planning for a small farm (large garden)


under farmworld, prodigy can come up with ways of having some combination
of raw crop (garlic, tomatoes, whatever is specified in the database)
by planting, harvesting, fertilizing, watering, and "grow"ing, which
is a sort of implicit operator in agriculture.  Whether the crop
grows at any particular time or not is dependent on three factors,
light (based on height of neighboring plants) fertilizer amount and
water amount (which are controllable directly) 

At the moment I haven't encoded any search control rules, so
the problem solver is limited to only coming up with 1 of a
particular product, and even that requires a little help from
"advise"  Once the sc-rules are done it should however be able to
come up with an arbitrary selection of product.

So far this has taken me about 130 hours to encode, most of which
was debugging.

a.
some things I was unable to model in prodigy:

1. formulae.  I wanted to have the growth be a factor that was
not a boolean value as to whether it could grow or not, but rather
a complex amount of growth that was dependent on a set of water
and fertilizer optimal needs and tolerance.  I found this was impossible
because if you're working backwards and have 3 factors into a formula, 
each of which can take on 10 different values, you backchain into
having 1000 different bindings for a variable.  Not fun.

b. I didn't find a single thing that was easy in prodigy.  I found
   it to be a long, painful bash-head-against-wall pull-teeth experience.

c. useful features of prodigy:  the debugger is of course useful, but
   it needs some work to be easy to use.

d. One modification I would make to prodigy:  Improve the debugger in
   some way to make it possible to debug in reasonable amounts of time.
   I found about 70-80% of my time writing this domain was spent in the
   debugger.  Another useful , but not essential thing I would modify
   is the ability to "HIDE" operators from the solution. (Like what
   happens to inference rules)  I would have used this for my "grow"
   operator, since it happens, but it's not exactly an operator per se.


there are a series of randomly-generated problems in probs/random?.lisp
made with the random problem generator "random" or random_gen.c.

even with all of the search control, this tends in many cases to generate
large search spaces.  look at the problem "p2" for a farily large 
problem that doesn't generate a large search space.



   
  


