6

Background: I am currently working on an 8-puzzle implementation of the original A Star algorithm and comparing this with a slightly modified algorithm which intends to improve node expansion (using additional information, ofcourse A Star in an equally informed unidirectional search has been proven optimal). The Open List of nodes are currently ordered by their F values (G-Cost+ H-Cost).

So in implementing this in Java I have set up a comparator which orders the List by their F-Values in ascending order.

       @Override
    public int compare(PNode o1, PNode o2) {
        return Integer.compare(o1.costF, o2.costF);
    }

Question: My question is whether:

  1. Is it permitted under A-star to implement a further Tie-breaker in A-Star using the Heuristic cost (H-Value) to break any deadlock with the F-Value among many nodes (where nodes exist with the same F-value in the Open List they will be ordered by the Heuristic value (H-Cost) in ascending order instead). The reason I am confused about this as the actual A star algorithm pseudocode only sorts the Open List by the F value.

Extending the same code above, the implementation will be:

        @Override
    public int compare(PNode o1, PNode o2) {
        if (o1.costF == o2.costF) {
            return Integer.compare(o1.costH, o2.costH);
        }
        return Integer.compare(o1.costF, o2.costF);
    }
  1. If this is permitted, are there any reasons why I should be wary of doing this? Logically I appreciate that ordering the Open List will be more costly. But from my experiments the difference do not seem significant enough to prevent me from using this.

Thanks so much everyone~

jwwnz
  • 703
  • 2
  • 7
  • 13
  • the heurstic can be altered to guarntee less points have equal F – Hussien Mostafa Dec 06 '21 at 11:10
  • Since A* sorts by f value, making them different means only one of the “equivalent” f values will be explored. One way to break ties is to nudge the scale of h slightly. If we scale it downwards, then f will increase as we move towards the goal. Unfortunately, this means that A* will prefer to expand vertices close to the starting point instead of vertices close to the goal. We can instead scale h upwards slightly (even by 0.1%). A* will prefer to expand vertices close to the goal. – Hussien Mostafa Dec 06 '21 at 11:11
  • The factor p should be chosen so that p <(minimum cost of taking one step)/(expected maximum path length) – Hussien Mostafa Dec 06 '21 at 11:12
  • A different way to break ties is to prefer paths that are along the straight line from the starting point to the goal: – Hussien Mostafa Dec 06 '21 at 11:13
  • https://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#breaking-ties – Hussien Mostafa Dec 06 '21 at 11:13

3 Answers3

6

Yes it is allowed, pretty much for the reasons stated in mcdowella's answer.

However, I'd like to add that it is often actually a very good idea, and much more beneficial than implied in that answer. This kind of tie-breaker can result in much more significant gains in performance than only finding the goal slightly earlier. See, for example, this page, which visualizes how A* still explores a rather massive area without the tie-breaker, and only a very narrow band along the optimal path with the tie-breaker.

Intuitively, you can understand that it is so effective by thinking of the different levels of "reliability" of G costs versus H costs. G costs are very reliable, they are ground truth, they are precisely the cost you have really already had to pay to reach a node. H costs are much less reliable, they are heuristics, they can be wildly wrong. By implementing the tie-breaker you propose, you are essentially saying "whenever two nodes have the same value for F = G + H, I prefer those with greater G and smaller H over those with smaller G and greater H". This is wise because, when the more reliable G component of F dominates the less reliable H component, F itself will also be more reliable.

Another major advantage is, as described on the page I linked to, that this tie-breaker can avoid exploring large portions of lots of different paths that are all equal and all optimal.

Dennis Soemers
  • 8,090
  • 2
  • 32
  • 55
3

I think this is OK for two reasons

1) You are only changing the behaviour in the case of ties, so all you are doing is selecting one possible execution path from a larger set of execution paths which are possible with the original version.

2) You preserve the property that if you retrieve the goal node from the open List, every other node in the open has G-Cost + H-Cost at least as expensive as that of the node you have just retrieved, and so must lead to a path to the goal node at least as expensive as the node you have just retrieved.

By favoring nodes with low heuristic cost in the case of ties, you are favoring any goal nodes in the case of ties, so I guess you might retrieve the goal node slightly earlier and so finish slightly earlier.

mcdowella
  • 19,301
  • 2
  • 19
  • 25
0

the heurstic can be changed to guarntee less points have equal F [ this article ] 1

The quick hack to work around this problem is to either adjust the g or h values. The tie breaker needs to be deterministic with respect to the vertex (i.e., it shouldn’t be a random number), and it needs to make the f values differ. Since A* sorts by f value, making them different means only one of the “equivalent” f values will be explored.

One way to break ties is to nudge the scale of h slightly. If we scale it downwards, then f will increase as we move towards the goal. Unfortunately, this means that A* will prefer to expand vertices close to the starting point instead of vertices close to the goal. We can instead scale h upwards slightly (even by 0.1%). A* will prefer to expand vertices close to the goal.

dx1 = current.x - goal.x
dy1 = current.y - goal.y
dx2 = start.x - goal.x
dy2 = start.y - goal.y
cross = abs(dx1*dy2 - dx2*dy1)
heuristic += cross*0.001

enter image description hereenter image description here

Hussien Mostafa
  • 159
  • 2
  • 18