Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion on algorithms #50

Closed
jiaweirobot opened this issue Apr 3, 2024 · 5 comments · Fixed by #51
Closed

Discussion on algorithms #50

jiaweirobot opened this issue Apr 3, 2024 · 5 comments · Fixed by #51

Comments

@jiaweirobot
Copy link

Hello, thank you very much for the code, the current algorithm is exceptionally fast to compute, but after referring to it I realized that the algorithm has some differences from the actual AStar algorithm. For example, the cost function of the AStar algorithm calculates the sum of the distances between the starting point and the target point preferentially, which is indeed fine without considering obstacles, but if obstacles are added, it is more similar to the (Greedy Best First Search) algorithm if you use the minimum heap, here is my actual test, is it designed this way on purpose?
image

@roy-t
Copy link
Owner

roy-t commented Apr 3, 2024

Hey! Thanks for your comments.

This is weird, in your example yellow is indeed not the shortest path (32 steps) and I can easily draw a path going south first that is shorter.

I haven't seen this show up in test cases. I do intend for this library to give you the truly shortest path. What did you mean by:

"the cost function of the AStar algorithm calculates the sum of the distances between the starting point and the target point preferentially"

Did you spot that in the code?

@roy-t roy-t linked a pull request Apr 3, 2024 that will close this issue
@roy-t
Copy link
Owner

roy-t commented Apr 3, 2024

I have created a unit test that, I think, mimics the picture you are showing: #51

But I can't reproduce the problem you have. In both directions the path finder finds the correct 25 step path, not the longer 32 step path. Are the coordinates I used the same as you used? Are you also sure that you are using the latest version?

image

@jiaweirobot
Copy link
Author

I'm using the latest version, I think maybe I made some adjustments on the parameters or I changed something that caused it, I'm checking it out, thanks for your support!

@jiaweirobot
Copy link
Author

jiaweirobot commented Apr 7, 2024

image
I found my problem, it's that I didn't calculate its travel time for the route, the travel time for each line is 0, that is, the parameter G is missing inside the A* algorithm, which causes it to degenerate to the GBFS algorithm (f(n)=G+H), after re-correcting it the result is correct, thank you, the problem can be closed now!

@roy-t
Copy link
Owner

roy-t commented Apr 7, 2024

Ah, that makes sense! Thanks for sharing that! Got me scared that I messed something up that only shows up in rare cases!

@roy-t roy-t closed this as completed Apr 7, 2024
roy-t added a commit that referenced this issue Apr 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants