I'm developing a path finding program. It is said theoretically that A* is better than Dijkstra. In fact, the latter is a special case of the former. However, when testing in the real world, I begin to doubt that is A* really better?
I used data of New York City, from 9th DIMACS Implementation Challenge - Shortest Paths, in which each node's latitude and longitude is given.
When applying A*, I need to calculate the spherical distance between two points, using Haversine Formula, which involves sin, cos, arcsin, square root. All of those are very very time-consuming.
The result is,
Using Dijkstra: 39.953 ms, expanded 256540 nodes.
Using A*, 108.475 ms, expanded 255135 nodes.
Noticing that in A*, we expanded less 1405 nodes. However, the time to compute a heuristic is much more than that saved.
To my understanding, the reason is that in a very large real graph, the weight of the heuristic will be very small, and the effect of it can be ignored, while the computing time is dominating.
I think you're more or less missing the point of A*. It is intended to be a very performant algorithm, partially by intentionally doing more work but with cheap heuristics, and you're kind of tearing that to bits when burdening it with a heavy extremely accurate prediction heuristic.
For node selection in A* you should just use an approximation of distance. Simply using (latdiff^2)+(lngdiff^2) as the approximated distance should make your algorithm much more performant than Dijkstra, and not give much worse results in any real world scenario. Actually the results should even be exactly the same if you do calculate the travelled distance on a selected node properly with the Haversine. Just use a cheap algorithm for selecting potential next traversals.
A* can be reduced to Dijkstra by setting some trivial parameters. There are three possible ways in which it does not improve on Dijkstra:
The heuristic used is incorrect: it is not a so-called admissible heuristic. A* should use a heuristic which does not overestimate the distance to the goal as part of its cost function.
The heuristic is too expensive to calculate.
The real-world graph structure is special.
In the case of the latter you should try to build on existing research, e.g. "Highway Dimension, Shortest Paths, and Provably Efficient Algorithms" by Abraham et al.
Like everything else in the universe, there's a trade-off. You can take dijkstra's algorithm to precisely calculate the heuristic, but that would defeat the purpose wouldn't it?
A* is a great algorithm in that it makes you lean towards the goal having a general idea of which direction to expand first. That said, you should keep the heuristic as simple as possible because all you need is a general direction.
In fact, more precise geometric calculations that are not based on the actual data do not necessarily give you a better direction. As long as they are not based on the data, all those heuristics give you just a direction which are all equally (in)correct.
In general A* is more performant than Dijkstra's but it really depends the heuristic function you use in A*. You'll want an h(n) that's optimistic and finds the lowest cost path, h(n) should be less than the true cost. If h(n) >= cost, then you'll end up in a situation like the one you've described.
Could you post your heuristic function?
Also bear in mind that the performance of these algorithms highly depends on the nature of the graph, which is closely related to the accuracy of the heuristic.
If you compare Dijkstra vs A* when navigating out of a labyrinth where each passage corresponds to a single graph edge, there is probably very little difference in performance. On the other hand, if the graph has many edges between "far-away" nodes, the difference can be quite dramatic. Think of a robot (or an AI-controlled computer game character) navigating in almost open terrain with a few obstacles.
My point is that, even though the New York dataset you used is definitely a good example of "real-world" graph, it is not representative of all real-world path finding problems.
Related
I have been implementing a star recently on one of my pathfinding visualisers. A common thing that i have noticed is that while it does return the shortest path, it sometimes fails to return the least cost path. Now i am unsure as to if, this is due to some implementation error or if this is not a characteristic of the algorithm on a whole. For reference, these are the outputs of the a star and dijkstras algo respectively:
So, why is this the case? (PS:the weights are 10, normal cost is 1 for any direction of movement and, the grey patches are walls)
A* is optimal. It will always return the least-cost path. But the heuristic value must be admissible.
A* may not return the least cost path, that is correct. This is a feature of A* though, not a disadvantage. To answer your question,
Why is it the case?
A* has a heuristics function that allows the algorithm to sacrifice accuracy for much higher performance by significantly reducing the area of search. This can be seen in your image too, where the Dijkstra's area of search is much wider. A* is often more useful in real-time games, where you don't necessarily need the lowest-cost path, as long as it is "good enough". Refer to this article for more examples. I find it explains A* very clearly in simple language.
As to what is "good enough", you define this using the heuristics function. Using different function will result in different behavior, allowing you to tune the algorithm to be optimal for your needs (depending on your playing field and accuracy requirement). You can also remove the heuristics, in which case it becomes simply the Dijkstra's algorithm. Refer to this article from the same site for some examples of heuristics.
A* gives a correct result provided the heuristic gives a lower bound to the true cost. Every possible path must have cost higher or equal to the value provided by the heuristic.
The algorithm becomes identical to Dijkstra's if you use a trivial heuristic that always gives the value 0.
To add to the correct answers by Md Asaduzzaman and Henry:
If the heuristic function is admissible, then A* tree search will
always find the least cost path.
(source)
An admissible heuristic is optimistic is an optimistic one: the heuristic cost should be less than or equal to the actual cost.
In other words, if your implementation does not return the lowest cost path, consider changing the heuristic to an admissible one.
I've been looking for an algorithm to efficiently compute an edit path between two trees, a path that does not have to correspond to shortest edit distance but preferably a relatively short one.
The case is that I have two directory trees, consisting of directories and files, and want to compute a sequence of deletes, inserts and renames that will transform one to the other.
I have tried searching both stackoverflow and the wild web but all I find is algorithms for computing shortest edit distance, but they all have high scaling factors.
So my question is, is there any more efficient way then for example "Zhang and Shasha" when I don't need the optimum distance?
Kind regards
There is the Klein algorithm that performs slightly better than "Zhang and Sasha", however it remains of very high complexity in both space and time for practical purpose.
There is an algorithm here that is in fact an heuristic, since the authors misused the term approximation.
It reduces the problem to a series of maximum weighted cliques for which it exists several approximation and heuristics, even a greedy approach could here perform reasonably well.
What is true for graphs is true for trees, you could therefore use a graph kernel convolution approach.
If you are looking for an off the shelf implementation (of an unspeficied algorithm, I woudl guess Zhang or Klein), you can check here
I'm in the process of writing an application to suggest circular routes over OpenStreetMap data subject to some constraints (the Orienteering Problem). In the innermost loop of the algorithm I'm trialling is a requirement to find the lowest cost path between two given points. Given the layout of the graph (basically Euclidean), the A star algorithm seems to be likely to produce results in the fastest time given the graph. However as well as distances on my edges (representing actual distances on the map), I also have a series of weights (currently scaled from 0.0, least desirable to 1.0, most desirable) indicating how desirable the particular edge (road/path/etc) is, calculated according to some metrics I've devised for my application.
I would like to modify my distances based on these weights. I am aware that the standard A star heuristic relies on the true cost of the path being at least as great as the estimate (based on a euclidean distance between the points). So my first thought was to come up with a scheme where the minimum edge distance is the real distance (for weight 1.0) and the distance is increased as the weight decreases (for instance quadrupling the distance for weight 0.0). Does this seem a sensible approach, or is there a better standard technique for fast routing under these circumstances?
I believe your approach is the most sane. Apparently I'm working on a similar problem, and I decided to use exactly the same strategy.
The A* algorithm doesn't necessarily rely on "true distances". It's not even about distances, you actually may minimize other physical quantity - the heuristic function should have the same physical units.
For instance, my problem is to minimize the path time, whereas the velocity at any given point depends on the location, time, and the chosen direction. My heuristic function is the rough distance (my problem is on the Earth surface, calculating the great circle distance is somewhat pricey) divided by the maximum allowed velocity. That is, it has units of time, and it's interpreted as the most optimistic time to reach the finishing point from the given location.
The relevant question is: "what do you actually want to minimize?". You need to end up with a single "modified distance", so that your pathfinding algorithm can pick the smallest one.
The continued usefulness of the A* algorithm depends on exactly how you integrate "desirability" into your routing distance. A* requires an "admissible heuristic" which is optimistic: the heuristic estimate for your "modified distance" must not exceed the actual "modified distance" (otherwise, the path it finds may not actually be optimal...). One way to ensure that is to make sure that the modified distance is always larger than the original, Euclidean distance for any given step; then, any A* heuristic admissible to minimize the Euclidean distance will also be admissible to minimize the modified distance.
For example, if you compute modified_distance = euclidean_distance / desirability_rating (for 0<desirability_rating<=1), your modified_distance will never be smaller than the euclidean_distance: whatever A* heuristic you were using for your unweighted paths will still be optimistic, so it will be usable for A*. (although, in regions where every path is undesirable, a highly over-optimistic A* heuristic may not improve performance as much as you would like...)
Fast(er) routing can be done with A*. In my own project I see a boost of approx. 4 times faster compared to dijkstra - so, even faster then bidirectional dijkstra.
But there are a lot more technics to improve query speed - e.g. introducing shortcuts and running A* on that graph. Here is a more detailed answer.
I am trying to find a optimal solution for the following problem
The numbers denoted inside each node are represented as (x,y).
The adjacent nodes to a node always have a y value that is (current nodes y value +1).
There is a cost of 1 for a change in the x value when we go from one node to its adjacent
There is no cost for going from node to its adjacent, if there is no change in the value of x.
No 2 nodes with the same y value are considered adjacent.
The optimal solution is the one with the lowest cost, I'm thinking of using A* path finding algorithm for finding an optimal solution.
My question, Is A* a good choice for the this kind of problems, or should i look at any other algorithm, and also i was thinking of using recursive method to calculate the Heuristic cost, but i get the feeling that it is not a good idea.
This is the example of how I'm thinking the heuristic function will be like this
The heuristic weight of a node = Min(heuristic weight of it's child nodes)
The same goes for the child nodes too.
But as far as my knowledge goes, heuristic is meant to be an approximate, so I think I'm going in the wrong direction as far as the heuristic function is concerned
A* guarantees to find the lowest cost path in a graph with nonnegative edge path costs, provided that you use an appropriate heuristic. What makes a heuristic function appropriate?
First, it must be admissible, i. e. it should, for any node, produce either an underestimate or a correct estimate for the cost of the cheapest path from that node to any of goal nodes. This means the heuristic should never overestimate the cost to get from the node to the goal.
Note that if your heuristic computes the estimate cost of 0 for every node, then A* just turns into breadth-first exhaustive search. So h(n)=0 is still an admissible heuristic, only the worst possible one. So, of all admissible heuristics, the tighter one estimates the cost to the goal, the better it is.
Second, it must be cheap to compute. It should be certainly O(1), and should preferably look at the current node alone. Recursively evaluating the cost as you propose will make your search significantly slower, not faster!
The question of A* applicability is thus whether you can come up with a reasonably good heuristic. From your problem description, it is not clear whether you can easily come up with one.
Depending on the problem domain, A* may be very useful if requirements are relaxed. If heuristic becomes inadmissible, then you lose the guarantee of finding the best path. Depending on the degree of overestimation of the distance, hovewer, the solution might still be good enough (for problem specific definition of "good enough"). The advantage is that sometimes you can compute that "good enough" path much faster. In some cases, probabilistic estimate of heuristics works good (it can have additional constraints on it to stay in the admissible range).
So, in general, you have breadth-first search for tractable problems, next faster you have A* for tractable problems with admissible heuristic. If your problem is intractable for breadth-first exhaustive search and does not admit a heuristic, then your only option is to settle for a "good enough" suboptimal solution. Again, A* may still work with inadmissible heuristic here, or you should look at beam search varieties. The difference is that beam searches have a limit on the number of ways the graph is currently being explored, while A* limits them indirectly by choosing some subset of less costly ones. There are practical cases not solvable by A* even with relaxed admissbility, when difference in cost among different search path is slight. Beam search with its hard limit on the number of paths works more efficiently in such problems.
Seems like an overkill to use A* when something like Dijkstra's would work. Dijkstra's will only work on non-negative cost transitions which seems true in this example. If you can have negative cost transitions then Bellman-Ford should also work.
I was reading about dijkstra algorithm and A* star algorithm. I know that the difference is the heuristic used. But what is a heuristic and how this influence the algorithms? Heuristic is just an way to measure the distance? But dijkstra considers the distance too? Sorry, but my question is about heuristic and what it means and why to use them... (I had read about it, but don't understant)
Other question: When should be used each one?
Thank you
In this context, a heuristic is a way of providing the algorithm with some form of extra evaluative information, so that the algorithm can find a 'good enough' solution, without exhaustively searching every possible solution.
Dijkstra's Algorithm does not use a heuristic. It expands outwards from the start node, and examines every node in the graph in order to find the shortest path. While this is accurate, it can be computationally expensive.
By comparison, the A* algorithm uses a distance + cost heuristic, to guide the algorithm in its choice of the next node to explore. This means that the algorithm finds a possible search solution without examining every node on the graph. It is therefore much cheaper to run, but at a loss of complete accuracy. It works because the result is usually close enough to the optimal solution, and is found cheaper than an exhaustive search of the entire graph.
As to when you should use each, it really depends on the application. However, using the A* algorithm requires an admissible heuristic, so this may not be applicable in situations where such information is unavailable to the algorithm.
A heuristic basically means an idea or an intuition! Any strategy that you use to solve a hard problem is a heuristic! In some fields (like combinatorial problems) it refers to the strategy that can help you solve a NP hard problem suboptimally within a polynomial time.
Dijkstra solves the single-source routing problem, i.e. it gives you the cost of going froma single point to any other point in the space.
A* solves a single-source single-target problem. It gives you a minimum distance path from a given point to another given point.
A* is usually faster than Dijkstra provided you give it an admissible heuristic, this is, an estimate of the distance to the goal, that never overestimates said distance. Contrary to a previous answer given here, if the heuristic used is admissible, A* is complete and will give you the optimal answer.