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

Quick implementation of diagonal heuristic calculation #12

Merged
merged 2 commits into from Mar 1, 2014
Merged

Quick implementation of diagonal heuristic calculation #12

merged 2 commits into from Mar 1, 2014

Conversation

ghost
Copy link

@ghost ghost commented Aug 24, 2013

I've just created a quick implementation of the diagonal heuristic calculation. Just wanted to share if you want to use it.

@bgrins
Copy link
Owner

bgrins commented Sep 4, 2013

Great, thanks for sharing! What values would you typically use for costStraight and costDiagonal, by the way?

I am thinking we should move the options into an object rather than overloading the function at this point. Basically all of the diagonal, heuristic, costStraight, costDiagonal seem like they should be passed in through an object instead of one by one. And maybe even start, end. I will think about that some more - do you have any thoughts about it?

@ghost
Copy link
Author

ghost commented Sep 6, 2013

I use costStraight = 1 and costDiagonal = Math.sqrt(2) as base values in my project.

Yes, moving the options for diagonal pathfinding into an object would be a good idea to simplify the function call. Whether start and end should also be included in that object I am not sure, as that could break a lot of code of people using the current style. I am tending to moving everything expect the grid parameter into that config object. In that scenario you can integrate a fallback if the second parameter is NOT an object, to support both styles.

@bgrins
Copy link
Owner

bgrins commented Mar 1, 2014

OK, I've landed this, thanks! Now I have some tests it would be great if we could cover this case: https://github.com/bgrins/javascript-astar/blob/master/test/tests.js.

@bgrins
Copy link
Owner

bgrins commented Mar 2, 2014

I've thought about this a bit more, and realized it would be easier if your defaults, 1 and Math.sqrt(2) were hardcoded directly into the heuristic rather than passed as options into the search call.

This way people could just pass in the diagonal heuristic and it would work automatically. Or if they wanted a custom heuristic they could copy yours as a reference implementation when making their own.

@ghost
Copy link
Author

ghost commented Mar 2, 2014

You are right, 1 and Math.sqrt(2) can be used as default values (I don't see any reason why anyone would use something else here).

@bgrins
Copy link
Owner

bgrins commented Mar 2, 2014

OK, I will update this after we land #18 (which adds another option to the parameter)

bgrins added a commit that referenced this pull request Mar 16, 2014
@bgrins
Copy link
Owner

bgrins commented Mar 16, 2014

OK, I have modified this with c5f2f20 to use your defaults instead of allowing them to be passed in

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 this pull request may close these issues.

None yet

1 participant