▲ 288 points
back
103 comments
The article doesn't explicitly state it in this manner in one concise place, but the way I would always think about A* from a "practical/easy-to-remember" perspective back when I was doing competitive programming is that they're all the same algorithm, but with different priorities on the priority queue:
Breadth-first Search: Priority is order of discovery of edges (that is, no priority queue/just a regular queue)
Dijkstra: Priority is distance so far + next edge distance
A*: Priority is distance so far + next edge distance + estimate of distance to target node.
This also helps me remember whether the estimate must over- or under-estimate: Since Dijkstra is making the estimate "0", clearly the "admissible heuristic" criteria must be an under-estimation.
Another way I like to think about it is that every graph traversal can be represented as a white set of unknown nodes, a grey set of known but unvisited nodes, and a black set of visited nodes. The data structure used to represent the grey set defines the algorithm:
DFS = queue
BFS = stack
Dijstra's = priority queue keyed by edge weight
A* = priority queue with heuristic function
Beam search = bounded priority queue with heuristic function
Topological sort = priority queue keyed by number of unvisited inbound edges
Copying garbage collector = pointer address
Mark & sweep garbage collector = dirty bit on the object pointed to
Generational garbage collector = multi-level grey set represented by the write barriers between each generation.
Breadth-first is a queue.
Depth-first is a stack.
A* is a priority queue.
> This also helps me remember whether the estimate must over- or under-estimate: Since Dijkstra is making the estimate "0", clearly the "admissible heuristic" criteria must be an under-estimation.
You're thinking too hard. :-) Just think of a map the same way a 10-year-old would.
Straight-line (Euclidean) distance is the most obvious heuristic on a map for estimating distance, and it's admissible.
Straight lines minimize distances i.e. they never overestimate. Which is enough to remind you that you want an underestimate.
> the way I would always think about A* from a "practical/easy-to-remember" perspective back when I was doing competitive programming is that they're all the same algorithm, but with different priorities on the priority queue
A much less obvious but much more fascinating (IMO) way to look at A* is that A* is actually Dijkstra but with a modified graph, where you adjust the heuristic delta between each edge's vertices to the edge's weight.
To remember the sign of the adjustment with this method, just imagine the next vertex getting super close to the destination, and then work out whether the weight needs to increase or decrease significantly in that case. (It needs to decrease, given you're getting closer to the destination.)
Which algorithm should I apply:
I have no information other than the fact that my agent has a decision to make (left or right).
- DFS or BFS
I have some information about the cost of the decision.
- UCS or Djikstra's algorithm
I have some idea of the cost of the decision, and a rough idea which direction the goal is in.
- A star
As well as knowing the cost, and a rough idea of the direction, I also know that I have a uniform cost grid.
- Jump point search
I think probably the easiest way to remember under/over is just to remember that euclidean distance is a very common admissible heuristic.
Any other tips for competitive coding ie a book or source of wisdom in a similar vein?
And depth first search is just a stack!
well they all just loop???
Red Blob Games is a great blog if you are interested in game development. The explanations are solid, they have at least pseudo code or an implementation for most of their posts, and they have great animations on a lot of their bigger posts to help build intuition.
I remember one of the Advent of Code challenges had a hex grid puzzle on it, and Red Blob Games hex grid guide was so good the site got hugged to death because of it for a while. Used that later when I built a civ clone too, it's a fantastic resource.
Red Blob Games is also "amitp", one of the earliest Google employees. #7 or something like that.
I came here to say the same thing. Red Blob Games is such a gold mine of resources for anyone looking to get into gamedev.
I have a deep love of A* because it was the first complex algorithm I fully understood. In my first data structures and algorithms in college (early 2000's), we had to pick an algorithm to study, code, and write a paper on and I picked A*.
I spent hours painstakingly drawing similar grids that the author of this article made and manually doing the calculations [0]. I still have these notes somewhere, even though they're over 20 years old at this point, because I was so proud of the work I put into it.
At any rate, thanks for this article and the trip down memory lane.
[0] https://imgur.com/a/zRYaodL (apologies for the Imgur link)
Interesting that this used to be called "AI". I'm still trying to figure out what to call the umbrella field of Artificial Intelligence now that "AI" has come to mean the genAI subset of DL which is a subset of ML which is a subset of what used to be called "AI".
> Interesting that this used to be called "AI".
What has been called AI in gaming in the past is rich and varied, and goes all the way down to a computer control opponent “seeing” a player and opening fire, moving towards, or moving away. Any code controlling NPC was referred to as “the AI of the game” even if all the code was doing was applying a few simple rote rules rather than following an exactly pre-specified sequence.
“AI” in gaming means (or has previously meant) a lot less than “AI” has meant in other fields, but with the increasing use of “AI” in all contexts this will soon no longer be the case.
The definition of "AI" has for a long time now been basically "We know it works somehow, but only few people really understand it", which is a moving target. At one point in the future, the LLMs we use today won't even be called AI anymore.
"Artificial intelligence" has always been a marketing term, not a technical one. John McCarthy coined the phrase when he was applying for a DARPA grant, and he picked it because he thought it would sound cool to the grant reviewers.
The way I explain it to my students is through a venn diagram of "Traditional AI", "Machine Learning", and "Data Science" (though I suppose Gen AI is starting to form another circle). A* falls into the "Traditional AI" space, which is a mixed of state searching, logic representation, and statistics/probability (now called data science). What general public considers "AI" is where all the circles meet, and it means everything from Robots to if-else statements.
> Interesting that this used to be called "AI".
I remember learning about A* in the AI lab at the University. Now these things sound trivial and we take them for granted. The joys of becoming old.
I took a course in grad school on "Game AI" that put different path finding approaches and methods of making decisions into a useful bucket away from ML and AI.
a lot of early ai was simply applied classical data structures and algorithms.
although perceptrons go back decades and decades.
Someone send this to the idiots at Garmin, because their navigators will tell you to drive in a straight line across mountains or water water to an unreachable destination. It's like AI that never says "I don't know".
As a game developer for a grid based puzzle game (https://thinky.gg - one of the games Pathology is a game where you have to go from Point A to Point B in shortest amount of steps).
I have found A* fascinating not because of the optimization but also from the various heuristics that can be built on top of it make it more generalized for other types of pathfinding.
Some devs have built solvers that use techniques like bidirectional search, precomputed pattern databases, and dead locking detection.
Just a note about bidirectional, or "double-ended" as I learned it - this can be very useful (i read 30% speed-up) for City / National Road searches.
One also has multiple layers of roadways of varying arterial significance, allowing higher speed (lower weight) travel, with real-world roads.
It was used at a mapping job to great boon by our backend.
I have this bookmarked under "path finding" along with
https://juhrjuhr.itch.io/deep-space-exploitation/devlog/9454...
Path finding visualization, highlighting A*: https://youtube.com/shorts/L8t0tt1Vrsw
Best introduction to A* in my opinion is travelling in Romania :)
AI a Modern Approach.
"This problem assumes that the reader is not familiar with Romanian geography. We apologize to those who are unable to take advantage of this pedagogical device."
(Or words to that effect, it's been 20+ years since I read it.)
I always use A* when going to Bucharest.
Funny enough I got a hit of nostalgia seeing this as I learned A* for a school project many years ago using this exact same tutorial.
I have a perhaps overly simplistic question, but how is this meant to be pronounced? A-star? Ah-sterisk?
Ay-star.
A* is simple enough, but how do you handle pathfinding when the environment isn’t known to the entity?
Iirc, the best approaches for this nowadays are machine learning based. Otherwise, you probably want to do an exploration step first, and bake in the environment.
Not to be confused with Sagittarius A*.
The star appears to have been cut off from the link, leaving an article about the corresponding radio source, Sagittarius A. This (official Wikipedia) short link leads to the desired article: https://w.wiki/5A7e
It's that time of year again. I like A* as much as the next one, but it seems a bit excessive a times.
Title should have a (2014) in it: Introduction to the A* Algorithm (2014).
1 points, 8 months ago, 1 comments: Introduction to the a* Algorithm (https://news.ycombinator.com/item?id=41897736)
202 points, 3 years ago, 30 comments: Introduction to the A* Algorithm (2014) (https://news.ycombinator.com/item?id=30287733)
4 points, 5 years ago, 1 comments: Introduction to the a* Algorithm (https://news.ycombinator.com/item?id=24146045)
201 points, 7 years ago, 14 comments: Introduction to A* (2014) (https://news.ycombinator.com/item?id=18642462)
5 points, 7 years ago, 0 comments: Introduction to A* (https://news.ycombinator.com/item?id=16190604)
Please consider some folks might be new to A*, and perhaps even HN, so maybe this is the first time they’ve seen it! :)
Also, I have ten books on perspective drawing, and my understanding isn’t complete without all ten of them
Or, if I’m teaching a subject on A*, perhaps ONE of those articles conveys the materials best for my students.
Thank you for providing links to the others though! I’m sure it will be helpful for someone.
I think A* deserves the popularity. It’s a simple variation on depth-first and breadth-first graph traversal that everyone learns in CS101, massively useful in some situations, yet for some reason isn’t a standard part of CS education. It’s a marvelous thing the first time you learn about it.
It’s even more marvelous if it helps you recognize that the difference between BFS and DFS is how you pick the next node to explore out of your bag of unexplored nodes. That symmetry is easily lost if DFS is only taught as a recursive algorithm.
Let it keep coming up every couple years to marvel a new generation of programmers.
I was surprised to see this article because it's not that time of year. Typically A* shows up around December, because people discover it via Advent of Code. (And that's the only place I've used it.)
I think it's just the first, most obvious thing to teach people just starting in pathfinding. It works in real life, it's easy to visualize and compute. Therefore all the tutorials are about it :)
I don't like A*
It's a performance hack, not how entities trying to get somewhere behave.