-
Notifications
You must be signed in to change notification settings - Fork 157
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
feat: Implement a k-d tree data structure #987
Conversation
48071e1
to
33bb449
Compare
33bb449
to
04b05f4
Compare
04b05f4
to
1d7c0dc
Compare
Codecov Report
@@ Coverage Diff @@
## main #987 +/- ##
==========================================
+ Coverage 48.67% 48.73% +0.06%
==========================================
Files 336 337 +1
Lines 17158 17281 +123
Branches 8098 8162 +64
==========================================
+ Hits 8351 8422 +71
- Misses 3100 3118 +18
- Partials 5707 5741 +34
Continue to review full report at Codecov.
|
Hmm, that test coverage is quite low. I'll work on improving that. |
1d7c0dc
to
d262185
Compare
I've updated the commit with the following changes:
|
d262185
to
c3200b2
Compare
This pull request is part three of four in my attempt to implement an orthogonal range search seed finder. k-d trees are datastructures which allow certain operations to be performed efficiently on point cloud data. Most commonly, these operations are (orthogonal) range search and nearest neighbour search. For my implementation, I need only the first, and as such nearest neighbour search is omitted in name of the YAGNI principle. I have implemented this class with performance and GPU-compatibility in mind, and therefore the memory is efficiently laid out wherever possible (although some improvements can still be made later). The implementation supports a more classical C++ interface where vectors of items are returned, as well as a more functional approach which employs higher-order functions to effect the required computation. This functional approach is the backbone to the classical approach as well. I believe that a k-d tree implementation is a good thing to have in Acts, since they are very versatile and I can see them being used in several other parts of the code. Again, I have added tests for the k-d tree as well, to ensure that the implementation works as intended.
c3200b2
to
7c95c47
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.
Very nice to get this together, I saw you fixed the doc
compilation already, so that's great.
I had two questions for my understanding, but other than that I am happy to merge this in.
So I've noticed the Mac OS CI build timed out; is that something that sometimes happens? Is the OS X build just slow? |
Ha, no idea, let's just re-start the CI and see. |
This pull request is part three of four in my attempt to implement an orthogonal range search seed finder. Parts one and two are #985 and #986.
k-d trees are data structures that allow certain operations to be performed efficiently on point cloud data. Most commonly, these
operations are (orthogonal) range search and nearest neighbour search. For my implementation, I need only the first, and as such nearest neighbour search is omitted in name of the YAGNI principle.
I have implemented this class with performance and GPU-compatibility in mind, and therefore the memory is efficiently laid out wherever possible (although some improvements can still be made later).
The implementation supports a more classical C++ interface where vectors of items are returned, as well as a more functional approach which employs higher-order functions to effect the required computation. This functional approach is the backbone to the classical approach as well.
I believe that a k-d tree implementation is a good thing to have in Acts, since they are very versatile and I can see them being used in several other parts of the code.
Again, I have added tests for the k-d tree as well, to ensure that the implementation works as intended.
This pull request cannot be merged until #985 and #986 are merged.