Newsgroups: comp.ai
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!swrinde!howland.reston.ans.net!nntp.coast.net!oleane!jussieu.fr!math.ohio-state.edu!usc!news.isi.edu!gremlin!shomase!jbarnett
From: jbarnett@shomase.NoSubdomain.NoDomain (Jeff Barnett)
Subject: Re: Search decomposition
Message-ID: <Du8HyB.KoH@gremlin.nrtc.northrop.com>
Sender: news@gremlin.nrtc.northrop.com (Usenet News Manager)
Reply-To: jbarnett@charming.nrtc.northrop.com
Organization: Northrop Automation Sciences Laboratory
References:  <31DD38E4.26C2@esumail.emporia.edu>
Date: Mon, 8 Jul 1996 17:01:23 GMT
Lines: 39

In article <31DD38E4.26C2@esumail.emporia.edu>, R Jones <jonesrob@esumail.emporia.edu> writes:
|> We are all familiar with bidirectional search.  But in some
|> problems one can use attributes of the initial and goal states to
|> find likely intermediate states. It is then possible to create
|> multiple bidirectional searchs between each of the pairs of identifiable
|> states (initial, goal, and all the intermediates).  This decomposition
|> of the search readily lends itself to implementation in parallel
|> systems.
|>      For example, in planning a trip from Los Angeles to New York
|> one might use the latitude and longitude of these initial and goal
|> states in order to define Denver and Kansas City as intermediate
|> stops along the route.  Bidirectional searchs could then be performed
|> between LA and Denver and between Denver and KC and between KC and
|> NY.  Each of these bidirectional searchs could be run in parallel and
|> perhaps could even be further decomposed into multiple searchs
|> themselves.
|>      Has anyone out there tried this?  I realize that a poor choice
|> of intermediate states will lead you to a less than optimal route.
|> 
|> R. Jones

Yes, such approaches have been tried many times.  However, there is
a big problem that you don't mention: unification of the partial
solutions.  Consider your traveling example.  Assume that the total
amount of fule must not exceed some threshold.  Now you can either
check this constraint when you combine the partial solutions OR
determine the fuel allocation to trip legs when you split the problem.
If you check, post solution, you might find that you don't have a
solution at all.  If you allocate the constraint, pre solution, you
are very unlikely to find anything near an optimal solution.
	This issue becomes worse when there are multiple constraints
that don't allocate easily.  For your example consider total travel
time, type of vehicle, inconvenience if you must change planes, etc.
If the problem decomposition produces (quasi-)independent problems,
paralellism works just dandy.  If too much dependency remains, then
the separated solvers must do alot of communication and that fact
destroys the hoped-for computational gains.

Jeff
