
John Carlson
johnc@cac.washington.edu

domain:  brew


Real World Problem

Brew will demonstrate a simplified version of the beer brewing process.
It incorporates the method of scheduling taken from the Schedworld
domain.  Certain portions of the process are scheduled, such as use
of the sink and use of an element on a stove.  Equipment can be put
through a rigorous sanitizing process or some portion of it.  At present,
only the wort-pot is automatically sanitized the rest of the equipment
would need to be stated in the goal statment.  Only the basic ingredients
are added: water, malt, hops, toasted barley and yeast.  The types of these
ingredients stated in the initial condition.  All processing is the same
for any type of beer.  With more time, I would have generalized the 
process to simulate more than one process.  Operators for the kegging
of the beer exist but are not actually incorporated into the process
(again due to the lack of time).  I am somewhat disappointed with the
outcome because I don't feel Prodigy was used to the fullest.



Simalar to existing Prodigy domain?

I was given access to a bottling and inventory domain which I did not
spend any time with because it wasn't the direction I was interested in.


Uses ideas from another Prodigy domain?

Yes, I used the ideas, methods and many of the functions of the schedworld.




approx.  40 hours  (over 10 days)



Project III
-----------

1) Analysis

   (a) Aspects which I was not able to model while using Prodigy (This is 
       not to say that it couldn't be done, since I'm certain that many
       features of Prodigy exist for which I am unaware or not familiar
       to the point of actually implementing.  Time was a constraint.):

	All the intangibles which may be difficult for any system to 
	model:  
		-Continuity in all the subtle aspects of brewing.
		  color
		  aroma
		  translucency
		  detection of variations in quality of malt, hops and
		  other vital ingredients
               
                -Temporal
		  since Prodigy is a linear planner, I found it difficult
		  to express the tasks which require simultaneous attention
		  




   (b) Potential problems which turned out to be manageable.

       I initially thought keeping track of the state of the numerous
       variables involved would be difficult.  The use of open world 
       predicates and inference rules made this task manageable.  Without
       the ability to handle open world predicates, the task would have
       been more than doubled.



   (c) Useful features:

       -The trace feature was probably the most used debugging tool
       
       -The ability to turn off state cycles helped in the pre-scr stage

       -It was nice to be able to see various aspects of the problem
	without exiting Prodigy. 
	Examples:
          initial, static, scrule, inference, operator,...

       -Of course, the ability to prune the search and customize Prodigy
	with the use of search control rules is invaluable.  Without
	search control rules, I would imagine that many (if not most) 
        problems would not be solvable with present technology (memory and
	speed).

       -The ability to create and use user defined functions is another
	feature which makes Prodigy very powerful and flexible.  This 
	aspect of Prodigy gives it the power already inherent in lisp
	and assimilates it into the Prodigy environment.



   (d) Modification or addition to Prodigy

       This may potentially cause problems, but I think it would be helpful
       if a simple mechanism for preventing Prodigy from re-checking
       preconditions (and therefore detecting goal-clobbering) existed.
       I had problems with goal-clobbering which were probably more related
       to poor style than a lacking on Prodigy's part.



