# Where does the heuristic come from in the A-star algorithm and how do we know it has the right properties?

I am trying to understand some notes regarding the A-star algorithm. The example used is to show how the algorithm can be used as a (more efficient) alternative to Dijkstra's algorithm for finding shortest path. I am reading about A* search starting page 71 of the UK GCE Computing textbook, Rouse to find shortest path. I have also read the Wikipedia entry - but to no avail. Two things do not makes sense to me.

(i) Where do the heuristic values for shortest distance come from? There is mention of "straight roads" but I don't understand this. I know "heuristic" is "informed guess" but why not values 1237, 978, 516, ... etc. or any other arbitrary, descending values for the heuristic distance "still to go" ?

(ii) What is the significance and meaning of "the heuristic must never make an over-estimate"? How do we know that, and why is it important? Surely all the intermediate distances before the completion of the A* algorithm are "over-estimates".

Regards,

Clive

(i) Where do the heuristic values for shortest distance come from? There is mention of "straight roads" but I don't understand this. I know "heuristic" is "informed guess" but why not values 1237, 978, 516, ... etc. or any other arbitrary, descending values for the heuristic distance "still to go" ?

When you decide to use A* to solve a problem, you need to design an appropriate heuristic. Designing a heuristic is a creative act, so one can't really give advice on how to do it. Ideally, though, the heuristic should give a good estimate of the true cost.

The purpose of the heuristic is to guide the search and a search that receives accurate guidance will terminate faster than one that receives poor guidance. There is, however, a trade-off. If your heuristic is perfect, then it will guide the search so well that the optimal route is the first one it examines. But, of course, if you could compute this perfect heuristic, you wouldn't need to be using search in the first place! Having a better heuristic means you spend less time searching, but you need to balance that against the fact that you'll probably spend more time computing this better heuristic.

(ii) What is the significance and meaning of "the heuristic must never make an over-estimate"? How do we know that, and why is it important?

You know it because you figured it out and you designed the heuristic to achieve that. The classic example is using straight-line distance as a heuristic for navigation. You know that the straight-line distance is the shortest possible distance between two points, so it cannot overestimate the distance you'd have to travel on the road network.

I wrote an answer a while ago about why it's important that you don't overestimate. Essentially, if you say "every route via X is long", the algorithm will first look at routes via other places, and potentially find one. When it finds an answer, it will stop. But it never considered routes via X so, if it turns out that the shortest route was via X, you missed it because your heuristic overestimated.

Surely all the intermediate distances before the completion of the A* algorithm are "over-estimates".

No. A*'s use of the heuristic means that, any time you expand a node in the search, you've found the shortest possible path to that node. So, every time you expand a node, you've found the optimal path to that node, plus an underestimating heuristic to the goal: all your intermediate states that get expanded are underestimates. There might be over-estimates in the frontier (i.e., suboptimal routes to intermediate goals) but they'll never get expanded.

One additional remark relating to point (i) of David's answer. Often, it does indeed make sense to come up with a heuristic manually, using and exploiting your domain knowledge about your specific search problem.

There are, however, also ways of deriving heuristics automatically, something that is routinely done in automated planning. These automatic approaches typically assume that the graph you want to search is given by a compact, structured model, where each node can be seen as an assignment of values to a set of state variables, and where the transitions are encoded by preconditions and effects on those state variables. Then, a very general idea of deriving heuristics automatically is to look at a simplified version of the model (and at the corresponding graph), to determine shortest goal distances in that simplified model, and to use those shortest goal distances as heuristic values when searching in the original graph.

For instance, one specific class of such heuristics are abstraction heuristics: many concrete nodes are represented by the same abstract node, so you get a smaller graph; whenever there is an edge in the original concrete graph, there must be a corresponding edge in the abstract graph; and start and goal nodes should be preserved. This guarantees that for every start-goal path in the original graph, there is also a corresponding start-goal path in the abstract graph that is at most as long as the original one. This then implies that the abstraction heuristic will never make an over-estimate.

Besides abstraction heuristics, there are also other classes of automatically derived heuristics in planning, like delete-relaxation heuristics, landmark heuristics, potential heuristics, etc.