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

feat!: Allow trimming other non measurement track states #3993

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

andiwand
Copy link
Contributor

@andiwand andiwand commented Dec 17, 2024

Adding new track state flags requires changing the trimming. Here I add an other case which should catch anything else which is not a measurement.

Non breaking if we keep the default.

Summary by CodeRabbit

  • New Features

    • Introduced an optional parameter trimOther to enhance track trimming functions, allowing for more granular control over track states.
  • Bug Fixes

    • Improved error handling and logic in the TrackFindingAlgorithm for better performance and robustness.
  • Documentation

    • Updated documentation comments for trimming functions to clarify the new parameter and its usage.
  • Tests

    • Updated test cases to reflect changes in trimming functions and adjusted expected outcomes accordingly.

@andiwand andiwand added this to the next milestone Dec 17, 2024
@andiwand
Copy link
Contributor Author

andiwand commented Dec 17, 2024

@pbutti discovered this after adding edge holes

Copy link

coderabbitai bot commented Dec 17, 2024

Walkthrough

Enhancements to track state manipulation, yes! A new optional parameter trimOther introduced in TrackHelpers.hpp, it is. Functions trimTrackFront, trimTrackBack, and trimTrack now allow selective trimming of non-measurement track states, they do. Default value, false, it remains, ensuring backward compatibility. Updated logic within these functions, checks for trimOther, it includes. Documentation comments revised, clarity provided, yes.

Changes

File Change Summary
Core/include/Acts/Utilities/TrackHelpers.hpp Added optional trimOther parameter (default false) to trimTrackFront, trimTrackBack, and trimTrack functions.
Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp Updated TrackFindingAlgorithm to use new trimTrack parameter; enhanced logic for BranchStopper and MeasurementSelector classes.
Tests/UnitTests/Core/Utilities/TrackHelpersTests.cpp Updated test cases for trimTrack functions to include new parameter; adjusted expected counts for track states.

Possibly related PRs

Suggested labels

automerge, Track Finding

Suggested reviewers

  • paulgessinger
  • pbutti

Poem

Trim the track, a Jedi's art 🚀
Parameters dance, new paths to chart
Flexibility flows like the Force
Measurement states find their course
Code evolves, wisdom unfurls 🌟

Tip

CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command @coderabbitai generate docstrings to have CodeRabbit automatically generate docstrings for your pull request. We would love to hear your feedback on Discord.


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a1b701d and be47d9e.

📒 Files selected for processing (3)
  • Core/include/Acts/Utilities/TrackHelpers.hpp (5 hunks)
  • Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp (1 hunks)
  • Tests/UnitTests/Core/Utilities/TrackHelpersTests.cpp (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • Core/include/Acts/Utilities/TrackHelpers.hpp
🔇 Additional comments (9)
Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp (1)

424-424: New parameter for trimming, helpful it is.
Expanding the trim function call to include 'other' states, you have. Ensures all non-measurement states, removable they become. Backward compatibility kept, strong the design is.

Tests/UnitTests/Core/Utilities/TrackHelpersTests.cpp (8)

Line range hint 92-102: Enhanced test data coverage, yes.
Provide varied track states, you do. Holes, measurements, outliers, shared hits—balance them well, you have.


107-107: Validate initial track states, good this is.
Confirm 11 states present, correct the test does.


113-113: Front trimming with new parameter, wise it is.
Include 'other' states, you do. Cohesion with the rest of the code maintained, yes.


116-116: Post-trim verification, correct count it shows.
Remain 9 states do. Properly the front states removed are, as expected.


122-122: Back trimming usage, consistent with the Force.
Extend coverage to remove extraneous states from the back, you do.


125-125: Double-check final states after back trim, validate we must.
Properly the track states reduce to 7. Aligned with trimming logic, it is.


131-131: Comprehensive trimming invoked, robust your approach is.
Call trimTrack with 'other' parameter, thoroughly tested, it appears.


134-134: Final checks, confirm correctness they do.
Remain 7 states we see. Reflects the new trimming rules properly, yes.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added the Component - Core Affects the Core module label Dec 17, 2024
Copy link

github-actions bot commented Dec 17, 2024

📊: Physics performance monitoring for be47d9e

Full contents

physmon summary

pbutti
pbutti previously approved these changes Dec 17, 2024
Copy link
Contributor

@pbutti pbutti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI bridge is failing, but to me the idea to add this feature looks ok.

@paulgessinger paulgessinger marked this pull request as ready for review December 18, 2024 07:39
@paulgessinger
Copy link
Member

@pbutti it just didn't run because the PR is still on draft.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2bb167c and a1b701d.

📒 Files selected for processing (1)
  • Core/include/Acts/Utilities/TrackHelpers.hpp (5 hunks)
🔇 Additional comments (3)
Core/include/Acts/Utilities/TrackHelpers.hpp (3)

415-415: Documentation clarity, improved it has been.

Clear and consistent documentation for the new parameter across all three functions, hmm yes. Well-documented changes, these are.

Also applies to: 457-457, 499-499


418-418: Backward compatibility, maintained it is.

Wise choice, making trimOther optional with default value false. Breaking changes, this prevents. Consistent parameter ordering across all functions, observed it is.

Also applies to: 460-460, 502-502


439-441: Implementation consistency, achieved it has been.

Identical logic for handling trimOther in both front and back trimming functions, implemented it is. Clear and concise condition !typeFlags.test(TrackStateFlag::MeasurementFlag), used it is.

Also applies to: 481-483

Core/include/Acts/Utilities/TrackHelpers.hpp Show resolved Hide resolved
@acts-policybot acts-policybot bot dismissed pbutti’s stale review December 18, 2024 09:00

Invalidated by push of be47d9e

@github-actions github-actions bot added Component - Examples Affects the Examples module Track Finding labels Dec 18, 2024
@andiwand andiwand changed the title feat: Allow trimming other non measurements states feat!: Allow trimming other non measurements states Dec 18, 2024
@andiwand andiwand changed the title feat!: Allow trimming other non measurements states feat!: Allow trimming other non measurement track states Dec 18, 2024
template <TrackProxyConcept track_proxy_t>
void trimTrackFront(track_proxy_t track, bool trimHoles, bool trimOutliers,
bool trimMaterial)
bool trimMaterial, bool trimOther)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
bool trimMaterial, bool trimOther)
bool trimMaterial, bool trimNonMeasurement)

?
Sounds a bit weird, but might be a bit clearer than other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also unhappy with the name. trimNonMeasurement sounds also a bit like it would to what the other flags do? which might actually be the case right now, I have to double check the logic. I think it would be good if they are all exclusive. So potentially trimOtherNoneMeasurement?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the problem is that it's not obvious from the signature what the remaining possibilities are.
I'm wondering: couldn't we pass in a TrackStateType object that we use as a mask instead of the named arguments?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component - Core Affects the Core module Component - Examples Affects the Examples module Track Finding
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants