Newsgroups: comp.ai.games
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in1.uu.net!news.iij.ad.jp!news.starnet.ad.jp!news.star-net.or.jp!aries.ogis-ri.co.jp!senri-nc!wincgw1!tokyonet.ad.jp!sectrl!mickey!agove
From: agove@im.isl.secom.co.jp (Andrew Gove)
Subject: Re: Best Path Algorithm
In-Reply-To: "Randolph M. Jones"'s message of Tue, 26 Mar 1996 10:09:42 -0500
Message-ID: <AGOVE.96Mar28184610@mickey.im.isl.secom.co.jp>
Sender: news@sectrl.isl.secom.co.jp
Nntp-Posting-Host: mickey
Organization: SECOM IS Lab., Tokyo, Japan
References: <4j71hq$klr@crchh327.rich.bnr.ca> <315808B6.167E@eecs.umich.edu>
Date: Thu, 28 Mar 1996 09:46:10 GMT
Lines: 77


Normally, I let other people reply to these, but looks like I got here
first :-).

   Tim Hardy wrote:
   > 
   > I posted a request here a short time ago for a best path algorithm.  I
   > appreciate the responses I received.  I ended up trying an algorithm
   > called A*, but I have the following problems.
   >   I've used the algorithm (A*), but I find it to be either correct and
   > terribly slow or fast and stupid on large (100x80) maps with varying
   > terrain.  I like the algorithm, but I need it to be much faster (it takes
   > 15+ seconds on a pentium-100 to get from one corner to the other on a
   > 100x80 map).  If I leave the heuristic most commonly mentioned in the
   > algorithm (dx^2+dy^2), the algorithm will not find the best path (it
   > plows through mountains it could easily have gone around) but it is very
   > fast.  If I lower the value of the heuristic (abs(dx)+abs(dy)) and raise
   > the weight of the terrain cost (most common - plains = 2 instead of one),
   > the algorithm now finds the true shortest path (it obviously considers
   > more alternate routes), but now takes 15+ seconds to do it.  In general,
   > if the heuristic is a large value and the terrain cost small, the
   > intelligence of the algorithm goes way down.  If I raise the value of the
   [...]
   > Tim

In article <315808B6.167E@eecs.umich.edu> "Randolph M. Jones" <rjones@eecs.umich.edu> writes:

>   Tim,
>      It sounds like you may be violating one of the rules of A* search.
>   A* should always be finding the best path as long as your heuristic is
>   admissible.  "Admissible" means that the heuristic evaluation of a path's
>   cost is *always* less than or equal to the true cost of taking the path.
>   Your comment "if the heuristic is a large value and the terrain cost small,
>   the intelligence of the algorithm goes way down" makes it sound like you
>   have rediscovered this principle.  A* will not give you the best path
>   if the heuristic value is actually larger than the terrain cost.

All true, and well said.

>   Given
>   this, I don't know why your heuristic of (dx^2+dy^2) isn't working.  The
>   only thing I can figure is that some of your terrain costs are less than
>   one (assuming dx and dy are counting unit grid squares).

First things first...
Tim, you mention "intelligence" of the algorithm.  Assuming you use an
admissible heuristic (i.e. optimistic, i.e. always too small), you should
*always* get the same answer.  Try using a heuristic that is always 0.
This will be slow, but if you don't get the shortest path, you've got a
bug in the A* algorithm.

Now, if that works, let's use a better heuristic.  (dx^2+dy^2) is too big.
That only works if you take the square root, so that it represents a
"as-the-crow-flies" distance, which of course is an optimistic estimate.
Or maybe not.  Read on.

If I'm reading correctly, abs(dx)+abs(dy) also didn't work until you doubled
the minimum terrain cost.  This leads me to believe that you are allowing
diagonal movement.  If so, then you could get from the square (0,0) to
(3,5) in only 5 moves.  However, your heuristic reports an optimistic
estimate of 8, and is therefore not admissible.  The heuristic you're
looking for is max(abs(dx), abs(dy)).

If you make movement more realistic and have diagonal moves cost sqrt(2)
times as much as cardinal moves, then the crow-flies heuristic is your
best bet.  Otherwise, diagonal moves tend to "warp space", making the
Euclidean distance formula invalid.

Keep working on it, and good luck.
Andrew Gove

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andrew Gove                                          <agove@im.isl.secom.co.jp>
$@9dIp(J $@!uN5(J  ($@%4!<%V(J $@%"%s%I%j%e!<(J)
Research Engineer  Image Processing Group    Tel 0425(34)5685  Fax 0425(34)5682
SECOM IS Lab.     T190 Tokyo-to Tachikawa-shi Sakae-machi 6-1-1 Tachihi biru #7
