Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Move sloppySin into SloppyMath from GeoUtils #14516
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
base: main
Are you sure you want to change the base?
Move sloppySin into SloppyMath from GeoUtils #14516
Changes from all commits
cb583a2
788564c
098e112
b502080
fe5b4f3
724acf9
299251a
63585a4
3cca3c0
0f3e47e
b59e17b
01c3a72
f510264
23f48e2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to promote this from an experimental API in GeoUtils to a non-experimental public API here?
If we really want to do this, let's keep in line with the existing methods in the file, and provide accuracy bounds and tests?
Personally I think an easier solution would be to "demote" it from GeoUtils to a package-private static method: seems like it is only used by Rectangle and it doesn't need to be public. This would be easier than "properly supporting it" IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @rmuir for the suggestions. While I agree it is easier this way, but IMO:
Had not realized myself that this promotes to non-experimental API. I have been bit sloppy with this SloppyMath stuff! :( Thanks for pointing and patiently reviewing so far.
That being said, I don't see any real harm with
sloppySin
getting promoted toSloppyMath
. I have added accuracy bounds and tests. Verified that the test ran without failure for 1000 iterationsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it is better to have the benchmark. I'm not familiar with what the Rectangle code is doing here: I don't tend to think about sin() being associated with Rectanges...
But the background is that the
cos()
andasin()
are needed for this use-case: https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/document/LatLonPointDistanceComparator.java#L37-L43We try hard to avoid calling these functions at all, but in some cases such as the sorting, many calls are needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sin()
is used for calculating and adjusting the longitude range of a circle's bounding Rectangle based on the latitude