Home/ Questions/Q 8296407
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T14:58:53+00:00

I have an application that would benefit from using A*; however, for legacy reasons,

  • 0

I have an application that would benefit from using A*; however, for legacy reasons, I need it to continue generating exactly the same paths it did before when there are multiple best-paths to choose from.

For example, consider this maze

...X
FX.S
....

S = start
F = finish
X = wall
. = empty space

with direction-priorities Up; Right; Down; Left. Using breadth-first, we will find the path DLLLU; however, using A* we immediately go left, and end up finding the path LULLD.

I’ve tried making sure to always expand in the correct direction when breaking ties; and overwriting the PreviousNode pointers when moving from a more important direction, but neither works in that example. Is there a way to do this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve come up with two ways of doing this. Both require continuing the algorithm while the top of the queue has distance-to-start g-value <= g(end-node). Since the heuristic used in A* is admissable, this guarantees that every node that belongs to some best-path will eventually be expanded.

    The first method is, when we come to a conflict (ie. we find two nodes with the same f-value that could potentially both be the parent of some node along the best-path), we resolve it by backtracking to the first point along the path that they meet (we can do this easily in O(path-length)). We then simply check the direction priorities of both paths, and go with whichever path would have the higher priority in a BFS-search.

    The second method only works for grids where each node touches the horizonally- and vertically- (and possibly diagonally-) adjacent nodes (ie. 4-connected grid-graphs). We do the same thing as before, but instead of backtracking to resolve a conflict, we compare the nodes along the paths from the start, and find the first place they differ. The first place they differ will be the same critical node as before, from which we can check direction-priorities.

    We do this by storing the best path so far for each node. Normally this would be cumbersome, but since we have a 4-connected graph, we can do this pretty efficiently by storing each direction taken along the path. This will take only 2-bits per node. Thus, we can essentially encode the path using integers – with 32-bit registers we can compare 16 nodes at a time; 32 nodes with 64-bit registers; and 64(!) nodes at a time with 128-bit registers (like the SSE registers in x86 and x64 processors), making this search very inexpensive even for paths with 100’s of nodes.

    I implemented both of these, along with @generic human’s algorithm, to test the speed. On a 50×50 grid with 400 towers,

    • @generic human’s algorithm ran about 120% slower than normal A*
    • my backtracking algorithm ran about 55% slower than normal A*
    • The integer-encoding algorithm only ran less than 10% slower than A*

    Thus, since my application uses 4-connected graphs, it seems the integer-encoding algorithm is best for me.

    I’ve copied an email I wrote to a professor here. It includes more detailed descriptions of the algorithms, along with sketches of proofs that they work.

    • 0