-
Notifications
You must be signed in to change notification settings - Fork 173
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
docs: Add comments grid iterator #2839
docs: Add comments grid iterator #2839
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2839 +/- ##
=======================================
Coverage 48.88% 48.89%
=======================================
Files 488 488
Lines 28244 28253 +9
Branches 13303 13307 +4
=======================================
+ Hits 13808 13813 +5
Misses 4827 4827
- Partials 9609 9613 +4 ☔ View full report in Codecov by Sentry. |
📊: Physics performance monitoring for fd91f49physmon summary
|
a325bc2
to
01fb179
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.
Looks good in general
Hi @niermann999 thanks for the comment. I have applied your suggestions |
Invalidated by push of fd91f49
Hi @niermann999 I had to make a minor change to fix a problem in the doc test ( This PR needs another approval for the CI to be happy |
A general class for defining a `BinnedGroup`. This class stores a `grid` (owns it), two `GridBinFinders` and a navigation pattern, optionally defined by the user. The PR also defines its iterator. This will replace the current `BinnedSPGroup` implementation, which is very specific. Also, creating and filling a grid cannot be generalized imho: variable definitions, selection cuts, number of axes and their ordering. As such, the creation and the filling of the grid are now handled externally, and not inside the `BinnedGroup` class, and it's the user's duty to make sure the filling happens. In my mind, all of this should be handled by the user for any custom way of doing it. One thing we can provide (as we currently do but I'm afraid is more a "nice consequence" then a "design") some pre-defined grids for specific geometries. For instance we can define a `CylindricalSpacePointGrid<external_spacepoint_t>` (as well as `CylindricalBinnedGroup<external_spacepoint_t>`) or a `TelescopeSpacePointGrid<external_spacepoint_t>` (and its `TelescopeBinnedGroup<external_spacepoint_t>`). These last points are not covered here, will be addressed in another PR once this one is in. My idea is to define these "specialization" as simple `typedef`s of the above generic classes, as well as defining functions for their creation and filling. This can be located inside a new `Acts/Seeding/detail` folder, so we can add as many specializations as possible. Requires: - #2838 - #2835 - #2839 (maybe optional?)
This adds some comments to the code to describe what the grid iterator classes do. It also adds two methods for retrieving the current local and global positions from the iterators, as well as adding some unit tests to check these newly-added methods. --------- Co-authored-by: Carlo Varni <carlovarni@pccvarni.dyndns.cern.ch> Co-authored-by: Carlo Varni <carlovarni@88-66-5a-25-b5-1f.dhcp.lbnl.us> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Carlo Varni <carlovarni@MacBook-Pro-di-Carlo-5.local>
A general class for defining a `BinnedGroup`. This class stores a `grid` (owns it), two `GridBinFinders` and a navigation pattern, optionally defined by the user. The PR also defines its iterator. This will replace the current `BinnedSPGroup` implementation, which is very specific. Also, creating and filling a grid cannot be generalized imho: variable definitions, selection cuts, number of axes and their ordering. As such, the creation and the filling of the grid are now handled externally, and not inside the `BinnedGroup` class, and it's the user's duty to make sure the filling happens. In my mind, all of this should be handled by the user for any custom way of doing it. One thing we can provide (as we currently do but I'm afraid is more a "nice consequence" then a "design") some pre-defined grids for specific geometries. For instance we can define a `CylindricalSpacePointGrid<external_spacepoint_t>` (as well as `CylindricalBinnedGroup<external_spacepoint_t>`) or a `TelescopeSpacePointGrid<external_spacepoint_t>` (and its `TelescopeBinnedGroup<external_spacepoint_t>`). These last points are not covered here, will be addressed in another PR once this one is in. My idea is to define these "specialization" as simple `typedef`s of the above generic classes, as well as defining functions for their creation and filling. This can be located inside a new `Acts/Seeding/detail` folder, so we can add as many specializations as possible. Requires: - acts-project#2838 - acts-project#2835 - acts-project#2839 (maybe optional?)
This adds some comments to the code to describe what the grid iterator classes do. It also adds two methods for retrieving the current local and global positions from the iterators, as well as adding some unit tests to check these newly-added methods.