# How can I make the A* algorithm give me the shortest path? (see picture enclosed)

I use Justin Heyes-Jones implementation of the astar algorithm. My heuristic function is just Euclidean distance. In the drawing attached (sorry for bad quality) a specific situation is described: lets say we are going from the node 1 to the node 2. The shortest way would go through the nodes a - b - c - d - e. But the step-by-step Astar with the Euclidean heuristic will give us the way through the following nodes: a - b' - c' - d' - e and I understand why this happens. But what do I have to do to make it return the shortest path?!

false shortest path finding by the astar

The code for the real road map import:

#include "search.h" class ArcList; class MapNode { public: int x, y; // ���������� ���� MapNode(); MapNode(int X, int Y); float Get_h( const MapNode & Goal_node ); bool GetNeighbours( AStarSearch<MapNode> *astarsearch, MapNode *parent_node ); bool IsSamePosition( const MapNode &rhs ); void PrintNodeInfo() const; bool operator == (const MapNode & other) const; void setArcList( ArcList * list ); private: ArcList * list; }; class Arc { public: MapNode A1; MapNode B1; Arc(const MapNode & a, const MapNode & b); }; class ArcList { public: void setArcs( const std::vector<Arc> & arcs ); void addArc( const Arc & arc ); size_t size() const; bool addNeighbours( AStarSearch<MapNode> * astarsearch, const MapNode & neighbour ); private : std::vector<Arc> arcs; }; std::vector <MapNode> FindPath(const MapNode & StartNode, const MapNode & GoalNode) { AStarSearch<MapNode> astarsearch; astarsearch.SetStartAndGoalStates( StartNode, GoalNode ); unsigned int SearchState; unsigned int SearchSteps = 0; do { if ( SearchSteps % 100 == 0) std::cout << "making step " << SearchSteps << endl; SearchState = astarsearch.SearchStep(); SearchSteps++; } while ( SearchState == AStarSearch<MapNode>::SEARCH_STATE_SEARCHING ); std::vector<MapNode> S; if ( SearchState == AStarSearch<MapNode>::SEARCH_STATE_SUCCEEDED ) { int steps = 0; for ( MapNode * node = astarsearch.GetSolutionStart(); node != 0; node = astarsearch.GetSolutionNext() ) { S.push_back(*node); // node->PrintNodeInfo(); } astarsearch.FreeSolutionNodes(); } else if ( SearchState == AStarSearch<MapNode>::SEARCH_STATE_FAILED ) { throw " SEARCH_FAILED "; } return S; }

Function FindPath gives me the vector of the result nodes.

Here is addNeighbours method:

bool ArcList::addNeighbours( AStarSearch<MapNode> * astarsearch, const MapNode & target ) { assert(astarsearch != 0); bool found = false; for (size_t i = 0; i < arcs.size(); i++ ) { Arc arc = arcs.at(i); if (arc.A1 == target) { found = true; astarsearch->AddSuccessor( arc.B1 ); } else if (arc.B1 == target ) { found = true; astarsearch->AddSuccessor( arc.A1 ); } } return found; }

and get_h method:

float MapNode::Get_h( const MapNode & Goal_node ) { float dx = x - Goal_node.x; float dy = y - Goal_node.y; return ( dx * dx + dy * dy ); }

I know that its not exact distance (no taking of square root here) - this is done to save some machine resources when evaluating.

## Answers

When you are using A* graph search, i.e. you only consider the first visit to a node and disregard the future visits, this can in fact happen when your heuristic is not consistent. If the heuristic is not consistent and you use a graph search, (you keep a list of visited states and if you have already encountered a state, you do not expand it again), your search doesn't give the correct answer.

However, when you use A* tree search with an admissible heuristic, you should get the correct answer. The difference in tree and graph search is that in the tree search you expand the state every time you encounter it. Hence even if at first your algorithm decides to take the longer b', c', d' path, later it returns to a, expands it again and finds out that the b, c, d path is in fact shorter.

Hence my advice is, either to use the tree search instead of the graph search, or choose a consistent heuristic.

For definition of consistent, see for example: Wikipedia: A* Search Algorithm

EDIT: While the above is still true, this heuristic is indeed consistent, I apologise for the confusion.

EDIT2: While the heuristic itself is admissible and consistent, the implementation wasn't. For the sake of performance you decided not to do the square root and that made your heuristic inadmissible and it was the reason why you got wrong results.

For the future, it is always better to first implement your algorithms as naively as possible. It usually helps to keep them more readable and they are less prone to bugs. If there are bugs, they are easier to spot. Hence, my final advice would be don't optimise unless you need it, or unless everything else is working well. Otherwise you may get into troubles.

It seems that taking the square root in get_h method has solved it. Turns out that my heuristic wasnt admissable (at least I think this explains it). Special thanks to Laky and justinhj for helping out with this!!!