Use signal_fraction for training particle classifier #2465
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2465 +/- ##
=======================================
Coverage 92.53% 92.53%
=======================================
Files 235 235
Lines 20024 20062 +38
=======================================
+ Hits 18529 18565 +36
- Misses 1495 1497 +2 ☔ View full report in Codecov by Sentry. |
LukasBeiske
force-pushed
the
gh_fraction
branch
from
16dff41
to
c04be4d
Compare
Tobychev
requested changes
Nov 21, 2023
LukasBeiske
force-pushed
the
gh_fraction
branch
from
c04be4d
to
1ad8b25
Compare
|
I'm not sure why this provenance test is failing right now. It works on my machine... Edit: Fixed by #2469 |
Tobychev
previously approved these changes
Nov 22, 2023
LukasBeiske
force-pushed
the
gh_fraction
branch
from
1ad8b25
to
b91dff2
Compare
Tobychev
previously approved these changes
Nov 23, 2023
LukasBeiske
force-pushed
the
gh_fraction
branch
from
b91dff2
to
bec01fc
Compare
Tobychev
previously approved these changes
Dec 14, 2023
maxnoe
reviewed
Dec 14, 2023
| # - [type, "LST*", 1000] | ||
| # - [type, "MST*", 1000] | ||
| # - [type, "MST*", 1000] # If not specified, as many events as possible are used. | ||
| signal_fraction: 0.5 # signal_fraction = n_signal / n_events |
There was a problem hiding this comment.
I would find it more intuitive I think to define the ratio?
I.e. 1.0 means use as much signal as background?
There was a problem hiding this comment.
I think signal fraction being how much signal is in the total is pretty intuitive.
There was a problem hiding this comment.
I think there are merits to both options:
- signal fraction in combination with
n_eventsmakes it a little bit more intuitive how many signal and how many background events are used, but we write out this information in the logs anyway. - signal ratio is maybe a bit closer to actual use cases, e.g. "Let's use twice as many signal events than background events".
I don't have a personal preference.
LukasBeiske
force-pushed
the
gh_fraction
branch
from
bec01fc
to
5ada7df
Compare
LukasBeiske
force-pushed
the
gh_fraction
branch
from
5ada7df
to
3e2e736
Compare
maxnoe
approved these changes
Feb 5, 2024
Tobychev
approved these changes
Feb 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes the
$$\texttt{signal\_fraction}= \frac{n_s}{n_s + n_b}.$$
n_signalandn_backgroundoptions ofctapipe-train-particle-classifier. Instead the total number of training eventsn_eventsand thesignal_fractioncan be chosen, whereIf
n_eventsis not specified, as many events as possible will be used considering the givensignal_fraction.