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

Add ability to manually specify invalid detectors #64

Merged
merged 15 commits into from
May 12, 2023

Conversation

MialLewis
Copy link
Collaborator

@MialLewis MialLewis commented Apr 28, 2023

Description of work:

This PR introduces a method to manually specify invalid detectors.

  • If detectors have been specified for a range (forward/backward), the algorithm designed to identify invalid detectors from fitting results will not run.
  • Invalid detectors are passed back and forth between the parent analysis algorithms and the child fit algorithms. They are cached after the first time they are identified and then are not identified again due to the above.
  • A method is provided add_invalid_detectors to add additional detectors if neccessary.

To test:
Check all unit and system tests pass.

Resolves #41

@MialLewis MialLewis force-pushed the 59_5_manually_enter_invalid_detectors branch from 1293de7 to cc58cbb Compare May 3, 2023 12:54
@MialLewis MialLewis marked this pull request as ready for review May 3, 2023 12:58
@MohamedAlmaki MohamedAlmaki self-requested a review May 9, 2023 12:21
@MohamedAlmaki MohamedAlmaki self-assigned this May 9, 2023
Copy link
Collaborator

@MohamedAlmaki MohamedAlmaki left a comment

Choose a reason for hiding this comment

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

LGTM! The tests have passed without any issues. I've noted a few personal code preferences, but ultimately the decision to change them is up to you.

raise AttributeError("desired range invalid - must represent either front or back detectors.")

@staticmethod
def _preset_invalid_detectors(invalid_detector_list_full_range, desired_range):
Copy link
Collaborator

Choose a reason for hiding this comment

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

It is common practice to reserve functions that start with an underscore for private members. Therefore, I recommend removing the underscore from any static members. It's your call, this is just a suggestion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm going to leave this - I added the underscore as I don't intend for this function to be called outside of the class despite it being static (maybe it shouldn't be, but it doesn't need to refer to any members etc.)

Copy link
Collaborator

Choose a reason for hiding this comment

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

ok

raise AttributeError("Spec list invalid - must represent either front or back detectors.")

@staticmethod
def _print_invalid_detectors(invalid_detectors, detector_range):
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is also a personal preference. In my opinion, it would be more natural to have this function as a private class member. To achieve this, we could modify the invalid_detectors to a boolean parameter, where True indicates front and False indicates back. Personally, I prefer to avoid using static members in class definitions whenever possible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've made this change - out of interest why do you prefer to avoid static members, I see conflicting advise regarding this?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It is just a personal preference. The use cases of the static function are limited as it cannot access class members. The only common use case I think is factory functions. I think in most cases it is better to extract the function as an external function. In your scenario, since all arguments of the function are private variables and it is only used internally, it is better from an encapsulation perspective to hide the function. I'm also interested to hear your perspective.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't have a strong opinion really. If I have a class member which does not access private member variables, if it is a function only likely to be used within that class I generally keep it within that class and mark it static. The static decorator just signals to the reader that it will not mutate any class members.

Copy link
Collaborator

@MohamedAlmaki MohamedAlmaki left a comment

Choose a reason for hiding this comment

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

Thanks for making the changes. Happy to approve it.

@MialLewis MialLewis merged commit 8586d87 into main May 12, 2023
@MialLewis MialLewis deleted the 59_5_manually_enter_invalid_detectors branch May 12, 2023 08:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor of new functions to handle invalid detectors
2 participants