Live data from Hacker News

Improving Heuristics for A* Pathfinding

redblobgames.com

21–30 of 42 posts

Re: Improving Heuristics for A* Pathfinding

#21
One of my fav LLM tests is asking it to implement A* algorithm, in X language, in a single file, output 80x40 char map with random obstacles and show the path. Ask it to build UI or change path heuristiscs, etc.

It's such a quick prompt but can quickly signal how useful the model is in that language or framework, how much you have to constraint output with specs and tests.

Re: Improving Heuristics for A* Pathfinding

#22
This Red Blob Games blog post would be accessible to a wider group of readers if it spent just a few sentences up front on motivation and terminology.

If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it.

And when you do finally get to that point, you realise it is all very simple, so why not just say that at the start?

Re: Improving Heuristics for A* Pathfinding

#24
I don't understand how the multiple landmarks works. If you just max all of the landmark distances wouldn't some landmark near the starting point eventually dominate as you move away from it? Once you get halfway through the path the useful landmarks would be returning lower and lower values while ones behind you return larger and larger values. Or just in general one far-away landmark would complete nullify any input from useful ones.

It seems to me that you would need a step to select useful landmarks but the code doesn't seem to do this and I don't see it discussed.

Re: Improving Heuristics for A* Pathfinding

#25

I don't understand how the multiple landmarks works. If you just max all of the landmark distances wouldn't some landmark near the starting point eventually dominate as you move away from it? Once you get halfway through the path the useful landmarks would be returning lower and lower values while ones behind you return larger and larger values. Or just in general one far-away landmark would complete nullify any inpu…

Ah, I figured it out. It is because he isn't using the distance to the landmark as the heuristic but the difference between the distance to the current location and the distance to the target. This means landmarks behind you will be negative (or useful in an undirected graph). This is also important for making the heuristic admissible as otherwise your heuristic would say zero when you are standing on top of the landmark.

Re: Improving Heuristics for A* Pathfinding

#26

This Red Blob Games blog post would be accessible to a wider group of readers if it spent just a few sentences up front on motivation and terminology. If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it. And when you do finally get to t…

Before reading about optimizing the A* algorithm, read about the algorithm itself first.

Re: Improving Heuristics for A* Pathfinding

#28
post #14
post #10

It uses df as an example, but it (unlike the others) has the problem that the set of valid paths between any two points can be constantly changing.

The landmark data can be calculated in a background thread. For DF I imagine you'd have a background thread running all the time, updating one landmark every so often. But what happens if you look for a path before the landmark data is updated? I haven't tested this yet but I believe this is how it'd work: 1. If the cost of a tile decreases, the precalculated heuristic will be too high, so A* might find a non-shortes…

One of the famous problems with df is that it's very much single threaded. At least the last time I checked, which is some years ago by now.

Besides that blocker, your idea sounds like a nice win.

Re: Improving Heuristics for A* Pathfinding

#29
post #15
post #3

Usually I would not point out a typo, but this one makes it difficult to grasp the magnitude of potential improvements: > the number of nodes A* has to explore decreases from 12693 to 12693

Good catch. I was thinking people would read that after they have moved the green L but I should handle both before and after moving L.

I'm also fairly certain I read a "helsp" instead of "helps" somewhere in the post

Re: Improving Heuristics for A* Pathfinding

#30

This Red Blob Games blog post would be accessible to a wider group of readers if it spent just a few sentences up front on motivation and terminology. If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it. And when you do finally get to t…

You’re asking for a different post. More like a science paper where they say the result up front.

This blog post is like a story. It doesn’t start with the ending.

I read your comment first, expecting to go to the article and see a bunch of undefined math terms, but that isn’t what happened at all.

Of course you need to know what a heuristic function is, so maybe you’re right in that sense. You absolutely do not need to know anything about landmarks to enjoy the post. I didn’t, and it was no trouble at all to follow.

Perhaps you found the “discovery” method of presentation not to your liking. Discovery means there’s a demo where you move the L around before its purpose is defined. Building an intuitive understanding before producing a rigorous definition is (now) considered a good teaching method.

Post reply on HN