X-Mailer: ELM [version 2.2 PL9]
Newsgroups: bit.listserv.csg-l
Date:         Mon, 31 Aug 1992 22:07:15 EDT
From:         "Jeffrey C. Hunter" <jeff@DRETOR.DCIEM.DND.CA>
Subject:      Re: Agre's Cooking problem
              at Aug 27, 92 10:57 am

[From Jeff Hunter (920831)]

	[Re: Bill Powers (920827.0800)]


	I'm planning to get around to a lot of posts, but I
Have to comment on Agre's program (called Toast)
	It was tasked with making a breakfast, and did so (in
simulation) expeditiously, whereas a STRIPS planner blew up after
6 hours.
	This was (if you pardon the pun) a cooked example. None
of the subtasks interfered with any other in any major way.
	To show why, here is an example of weekend goals:

	- wear sunhat
	- get new car tires
	- spend weekend at cottage

	And these are fed into Agre's weekend planner (main mechanism
recapped below):

>While there are unsatisfied goals,
>    Choose aribtrarily an unsatisfied goal.
     ... use available tools and resources to satisfy goal.


	[pick a goal: spend weekend at cottage]
- walk to car
- enter car
- start driving to cottage
	[slack time. try other goals]
	[cannot wear hat. cannot walk to closet. am driving]
	[cannot drive to repair shop. am driving to cottage]
- arrive at cottage	[goal #3 in progress]
	[pick a goal: wear sun hat]
- walk to closet	[at home!]
- wear hat		[goal #2 satisfied]
	[pick a goal: get tires changed]
- walk to car 		[at cottage!]
- drive to repair shop
- exit car. wait for tire change
	[slack time. try other goals]
	[pick a goal: spend weekend at cottage]
	[car unavailable. no problem]
- walk to cottage
- arrive at cottage	[goal #3 in progress]
	[pick a goal: get tires changed]
- walk to car
- remove car from repair shop
	[pick a goal: spend weekend at cottage]
- drive to cottage
- enjoy weekend		[soaking your feet]


	Since all goals require movement they all conflict. A bad
choice of goal ordering can make for a considerable amount of
walking!
	Any decent planner can find the best ordering for these
weekend goals in nearly the same time that Agre's one would
find a lousy one.
	The "planning weenies" have considered a lot of cases of
conflicting tasks, and their work should not be discarded lightly.


>  To insure that the breakfast maker problem was not entirely trivial,
>  we implemented a STRIPS formalization of a subset of the domain and
>  tested it using the SNLP non-linear planner [ref] on the omelette
>  making subproblem...
>  ...(The planner ran for 6 hours on a Symbolics XL1200
>  before exhausting its paging disk). The planner was able to make
>toast
>  and set the table however.
>
>If this is what is meant by "too much machinery," I get the point. 6
>hours!

	I think I see why the planner died. At least part of it
is that Toast is implicitly told that any pat of butter is the
same as any other pat, whereas the SNLP planner was not.
	Why are there 15 pats of butter? Why so that the planner
must consider more than 23 factorial orders of placing butter
and eggs in the frypan.


	Agre seems to have some good points, but don't swallow
his breakfast without a few grains of salt.
		... Jeff
--
De apibus semper dubitandum est.	Winni Ille Pu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU