0

I've read through a few stackoverflows on this topic, as well as the wikipedia on A* but I'm still a little confused. I think this post almost explained it completely to me: A* heuristic, overestimation/underestimation?

My only confusion left is, how does the A* know the optimal solution? It seems like with an admissible heuristic, you can throw out paths that exceed the known optimal solution, because the heuristic is guaranteed to be less than or equal. But how would A* know the optimal ahead of time?

Would this search work and guarantee an optimal solution if you didn't know the optimal path cost?

Community
  • 1
  • 1
Kevin
  • 3,209
  • 9
  • 39
  • 53

2 Answers2

1

A* does not know the optimal solution, the heuristic gives only an educated guess which helps to accelerate the search process. Seeing that you already read some theoretical explanations, let's try a different approach here, with an example:

enter image description here

  1. Starting at the green node, A* explores the node with the smallest cost + heuristic (1.5 + 4 = 5.5, node 'a'). Cost + heuristic can be read as "how much until there plus how much I think is left to the goal". In other words, it's the estimated total cost to the goal. So it makes sense that we select the smallest value. Node 'd' has a higher cost (2 + 4.5 = 6.5), so we just leave it at the queue.
  2. By expanding 'a' neighbors, we add 'b' to the queue and compute its value, which is 1.5 + 2 + 2 = 5.5 (cost until there in bold, the other term is how much I think is left). It is still better than the cost for 'd', so we keep exploring this path. Note that the heuristic in 'b' is 2, which means that we think that this is the addional cost remaining to get to the goal... which is clearly wrong, there is no way to get there from 'b' with cost 2! But it poses no problem to the A* algorithm, because we are underestimating the real cost.
  3. Expanding 'b', we add its neighbor 'c' do the queue with value 1.5 + 2 + 3 + 4 = 10.5. Now, remember that 'd' is still in the queue? And now it has the smallest value (6.5), so we leave 'c' in the queue and try 'd' because it is a more promising path. This decision is possible because we know that it has a cost of 6.5 only to get to 'c', and we think that there is still a cost of 4 to get to the goal. In this case, the heuristic is correct, which is also ok for the A* algorithm.
  4. By expanding 'd' we add 'e' to the queue with value 2 + 3 + 2 = 7. The heuristic here is correct, which we already know that is ok for A*. Then we would explore 'e' and find the goal. But let's suppose we had h(e) = 6, giving 'e' a value of 2 + 3 + 6 = 11. It would mean that 'c' would be the next best guess (10.5) and we would try a hopeless path! It means that overestimating the heuristic is not admissible, since it makes A* take the wrong exploration path.

If you're looking for proofs, here is an informal one from Wikipedia for admissibility:

When A* terminates its search, it has found a path whose actual cost is lower than the estimated cost of any path through any open node. But since those estimates are optimistic, A* can safely ignore those nodes. In other words, A* will never overlook the possibility of a lower-cost path and so is admissible.

And for optimality:

Suppose now that some other search algorithm B terminates its search with a path whose actual cost is not less than the estimated cost of a path through some open node. Based on the heuristic information it has, Algorithm B cannot rule out the possibility that a path through that node has a lower cost. So while B might consider fewer nodes than A*, it cannot be admissible. Accordingly, A* considers the fewest nodes of any admissible search algorithm.

You may also want to check this video: A* optimality proof.

rcpinto
  • 4,166
  • 2
  • 24
  • 25
  • Thanks for the explanation! I haven't had a chance to watch the A* video yet so this question may be answered in that video, but when A* terminates it's search, how is guaranteed that the path it found is optimal? For example, say you have 2 paths A and B. Path A has a cost of 3, and Path B has a cost of 4. So here, path A is the optimal path. But the heuristic guides us to try Path B first. In this case, once we've tried Path B, we've found a solution and terminate, but it's not the optimal solution. How does A* handle this? – Kevin Jun 01 '16 at 18:03
  • A* ends when you take the goal state from the queue, not when you add it. And since the queue is ordered by cost, it means that you always get the shortest path. – rcpinto Jun 02 '16 at 03:15
  • But the queue is ordered by actual cost + heuristic cost right? So back to my example of Path A and Path B. Path A has an actual cost of 3, and Path B has an actual cost of 4. Path B has a heuristic of 1, and Path A has a heuristic of 3. This remains an admissible heuristic because we never overestimate the cost of the path. Now, Path B has a overall lower cost (4+1 vs 3+3), so Path B would be explored first and we'd find the goal state, even though Path A has the actual lower path. – Kevin Jun 02 '16 at 03:27
  • If you found the goal, the heuristic must be relative to its node. Since the heuristic never overestimates, it _must_ be 0 for the goal, always. Wrong estimates in intermediate nodes don't affect the stop criterion, so there is no issue with your example. You may find the goal through the worse path first, but it won't be put in the first slot of the queue. The heuristic refers to the last node in the path only, which in this case would be goal, and so h=0. – rcpinto Jun 02 '16 at 03:46
  • So in the graph in the example above, let's assume we get to the point where the only 2 nodes left in our queue is c and e. So the next node we explore will give us the goal state. The cost to c is 6.5, and the cost to e is 5. Currently, our heuristic will lead us to explore e first which is optimal. Let's say that e->goal actually has a cost of 3 and has a heuristic of 3 (so we don't overestimate), while c->goal has a heuristic of 1. Now, c->goal has a cost of 6.5 + 1 = 7.5, while e->goal has a cost of 5 + 3 = 8. This would lead us to explore c first, which is not the optimal path right? – Kevin Jun 02 '16 at 04:58
  • Yes, then you add the goal to the queue with total cost 10.5. At the next step, you still have that 'e' with cost 8 in the queue and it will be explored, finding the goal with a smaller cost (whenever a node that's already in the queue would be added again, you just update the cost if it is smaller). – rcpinto Jun 02 '16 at 05:19
  • Interesting. So even though we found the goal through node c, our A* search would still continue and try e? – Kevin Jun 02 '16 at 05:23
  • Yup. Since there was a shorter path in the queue, it knows there is chance of finding a shortest path to the goal and keeps trying. – rcpinto Jun 02 '16 at 05:25
0

It achieves it by passing through all possible variants/chances using heuristic method. So you will have all needed tiles/vertices/waypoints in you closed list.