-
Notifications
You must be signed in to change notification settings - Fork 41
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
Add an example using custom distance for nearest search #1115
Conversation
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.
I would drop the callback to reduce complexity and explore defining struct MyPoint { float x, y; };
|
||
// Expected output: | ||
// offsets: 0 2 | ||
// distances: 0.5 1 |
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.
Why did you elect to get distances out instead of indices?
I suspect indices would make it more obvious that the distance metric was changed.
I find the use of both a custom geometry with specialized distance computation mixed with a callback that recomputes the distance potentially confusing.
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.
I chose distances so that a user can see that the computed distances are indeed the custom ones. Computing just the found indices seems insufficient to me, as it still does not confirm that we can get the correct distance in the callback.
The whole point is for a user to not define their own type. The only thing that's necessary is to have a separate type for disambiguation during the dispatch. |
@dalg24 Do you have any blocking objections to merging the example in the current form? |
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.
Formally blocking. I find the complexity unnecessary (along the lines of my previous comments)
@dalg24 If you find complexity unnecessary, please provide a reply to this comment. |
f3e66e6
to
c0fb243
Compare
c0fb243
to
1a4572f
Compare
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.
Please fix the header includes before you merge
// Provide the required centroid function for the custom data type | ||
KOKKOS_FUNCTION auto returnCentroid(CustomPoint const &point) { return point; } |
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.
How comes we don't default that implementation?
(not blocking but we should consider fixing)
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.
We do. I removed it. It was from the time when CustomPoint
did not have operator[]
, and returnCentroid
returned ArborX::Point
and not CustomPoint
.
Co-authored-by: Damien L-G <[email protected]>
Add an example that does nearest search using custom points and metric.
Drive-by change: remove couple unnecessary headers