Add a-star path finding algorythm.

[wlame]

• added a_star function with the same signature as dijkstra
• added a 'radius' parameter to BlockageGrid constructor
• some minor improvements

[maxtropets]

I think you're missing a check for g_score[current] == current_g_score. You shall not continue this iteration if that's not true.

Unlike Dijkstra, A* may give you a worse (by g_score) hex first, unless your heuristic function guarantees the opposite.

Without this check it may actually perform way worse.

[maxtropets]

I wonder if it also may give you not the shortest path here?..

[wlame]

If I got you correct that condition will allways be met.
In current_g_score we have the minimum value of g-scores needed to get to the final end hex. It is guaranteed by the heap, based on the f_score, which will differ from g_score by the constant value of last step (f_score = g_score + heuristic(neighbor)). So minimal f_score means minimal g_score.

⬆️ That was not an AI comment I promise. Despite I also use . at the end of sentenses.

[wlame]

I would be happy to setup test that proves the opposite and dig inside to figure out what am I missing.

[maxtropets]

So minimal f_score means minimal g_score.

Why do you need both f and g then?

[wlame]

Because those mean different things — minimal cost to get to currect cell and estimation cost to get from current cell to target.

[maxtropets]

My claim is - it magically works because of the simplicity of the current heuristics. If you were to add some more penalties (let's say, you want the most straight (fewer turns) path), then you may end up getting wrong results.

[maxtropets]

It means that you have to sort by the score which determines what's your best result, and if you're not - than you have to check your current g_score is the best before printing result. So the check I'm talking about should happen earlier.