-
Notifications
You must be signed in to change notification settings - Fork 28
feat: Add frequentist coverage intervals module #176
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
Conversation
|
I don't think I need to list "add tests for intervals module" to the squashed version, that should be implied by adding the module. :) |
SGTM. I've revised the PR body. 👍 |
| missing = np.where(values == 0) | ||
| available = np.nonzero(values) | ||
| if len(available[0]) == 0: | ||
| raise RuntimeError( |
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.
Inconsistent with docstring. I would suggest warnings.warn with a RuntimeWarning.
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.
Henry had suggested the RuntimeError and I had forgot to upate the docstring. Why should this be a warning though vs. an error? If everything is zero then something is wrong.
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.
It's valid to plot an empty histogram with error bars, certainly if the data is not scaled then you even have a well-defined error bar. The interpretation of them can be challenging if the data is scaled, however, and there's no way to tell other than the user. Either way it seems we should not throw an exception.
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.
It's valid to plot an empty histogram with error bars
Why are you plotting non-existent data? If the histogram is actually empty this doesn't make sense. Link to an example?
Also, why are you taking a ratio of anything that is non-existent? This makes even less sense to me. :? An example would be helpful.
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.
Isn't this poisson interval method used for plain errorbar histos (as well as ratios)? For ratios sure makes less sense. But imagine you are dumping 100 region plots to a file, now if one region is empty do you want your plot dumper script to crash or emit a warning?
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.
But imagine you are dumping 100 region plots to a file, now if one region is empty do you want your plot dumper script to crash or emit a warning?
IMO it should crash. It is your responsibility to clean your data.
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.
Ok, its a valid opinion. Just seems at odds with the amount of work this routine does to make up vaguely reasonable error bars in the case where even all but one bin is zero, that it would give up if all are zero. I won't press the issue further then (except to update the docstring)
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.
If you expect it to crash, that's what try/except (or using "if" beforehand) is for. This could mask real problems, like all plots being empty because something is misconfigured? Nobody reads logs; warnings are next to useless.
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.
Isn't this poisson interval method used for plain errorbar histos (as well as ratios)?
In practice it could be, but at the moment it is only being used in ratio_uncertainty.
Just seems at odds with the amount of work this routine does to make up vaguely reasonable error bars in the case where even all but one bin is zero, that it would give up if all are zero
I see what you're saying, but then would you also suggest not allowing any empty values? Or how would you define the cutoff? I don't think that you're pressing anything, I just want to make sure that I understand what your thoughts are here as it is clear that you've thought about this far more than I have.
(Henry I think we're in agreement but if I'm misunderstanding (sorry) please let me know).
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.
The all zero case is the only situation when there really isn't enough info to do something reasonable so its fine. LGTM
| with np.errstate(divide="ignore"): | ||
| ratio = num / denom | ||
| if uncertainty_type == "poisson": | ||
| ratio_uncert = np.abs(poisson_interval(ratio, num / np.square(denom)) - ratio) |
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.
Maybe some more docs on what this is would be helpful? I am actually not sure what it is, poisson for numerator?
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.
I looked back at my code to see that indeed it is poisson for numerator. :)
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.
I'm switching work at the moment, but I'll come back tonight and clean this up and make it more clear.
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.
Poke me when ready. :)
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.
Poke me when ready
sorry I missed this comment. poke.
| elif uncertainty_type == "poisson-ratio": | ||
| # poisson ratio n/m is equivalent to binomial n/(n+m) | ||
| ratio_uncert = np.abs(clopper_pearson_interval(num, num + denom) - ratio) | ||
| else: |
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.
Would be nice to add as well the simple propagation of error style uncertainty: https://github.com/CoffeaTeam/coffea/blob/84e805773c1fac32fc79bc9373ec324552371244/coffea/hist/plot.py#L82
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.
Sure, but is that needed in this PR to get things up and going for PR #161? That could be added later.
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.
Feel free to open as an issue and move forward with this for now. :)
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.
Considering its the ROOT default ratio plot error (TH1::Divide) seems we would want that no?
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.
Considering its the ROOT default ratio plot error (
TH1::Divide) seems we would want that no?
Let me go look, but I'm not sold on this argument. ROOT does plenty of things that are not a good idea.
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.
I also do not consider ROOT's warning vs. error behavior to be a design standard for us. :)
Now if there's a valid reason to do this, then why is there a warning? And if not, why not just error now?
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.
(If it's valid but rare, warnings can be squelched, while error's can't be)
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.
I didn't add it originally either, but it is valid in some cases. See the PR that added it to coffea: scikit-hep/coffea#182
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.
I didn't add it originally either, but it is valid in some cases.
Looking back at that Issue it is brought up that
Ah yeah, fair enough, this would be needed for efficiencies derived from weighted data (which is kind of rare, but definitely happens).
But the specific example isn't really elaborated on. Can you either ELI5 why this is worth doing now, or make a new Issue from this discussion and it can get labeled as a "good first issue"? Again, you've thought about this all more than I have, so it is very possible I'm just not seeing something incredibly obvious to you.
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.
I thought it would be convenient to copy it as the others, since it isn't much work. But also fine to put it off to later if you prefer. I can make the issue
|
@all-contributors please add @matthewfeickert for code |
|
I've put up a pull request to add @matthewfeickert! 🎉 |
eb13b6b to
aa09c83
Compare
Sourcery Code Quality Report❌ Merging this PR will decrease code quality in the affected files by 0.06%.
Here are some functions in these files that still need a tune-up:
Legend and ExplanationThe emojis denote the absolute quality of the code:
The 👍 and 👎 indicate whether the quality has improved or gotten worse with this pull request. Please see our documentation here for details on how these metrics are calculated. We are actively working on this report - lots more documentation and extra metrics to come! Let us know what you think of it by mentioning @sourcery-ai in a comment. |
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.
LGTM, thanks!
Add frequentist coverage intervals as a module (based off those added by @nsmith- to
coffea) which will be used in PR #161.Preview of relevant changes to docs: https://hist--176.org.readthedocs.build/en/176/reference/hist.html#module-hist.intervals
Suggested squash and merge message