-
Notifications
You must be signed in to change notification settings - Fork 23
feat: Improve handling of parameter bounds when computing impacts in ranking #512
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
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #512 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 22 22
Lines 2096 2117 +21
Branches 291 297 +6
=========================================
+ Hits 2096 2117 +21 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
f01114d
to
62fc8e3
Compare
62fc8e3
to
88da653
Compare
@alexander-held this is ready for review now with tests. If I fix the partially covered line (by switching |
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 am wondering if there is a case where users would want use_suggested_bounds=False
and where bounds would be applied if the setting was turned on instead. For cases where bounds are not applied regardless, this setting does not do anything. All cases I can think of would cause problems in terms of crashes or unreasonable results if bounding would be needed but is not applied. This situation means that parameter uncertainties are already large when compared to the distance of the best-fit point to the boundary, so they cannot necessarily be trusted to begin with, so it's not clear to me that the unbounded calculation is producing anything meaningful.
@alexander-held --- thoughts on this? Otherwise, think this is ready. |
The partial coverage question is no longer relevant now, right? With the restructuring this looks fine. |
This is based on #490. Closes #511.
Summary
When building parameter rankings based on impact, 5 fits must be evaluated for each NP. The fits are evaluated at:
The uncertainties so far have been extracted from the Hessian. If the bounds of the parameter, which specify valid range of values of this parameter, are not specified by the user, one of the NP values above may step out of the appropriate bound. For example, for a poisson-constrained NP (
shapesys
). If the best-fit value is1.0
and pre/post-fit uncertainty is>1
, the NP value will be negative for some of the above fits. Negative parameter values are not allowed in the poisson terms, and hence the corresponding fits fails.This can indicate a defective model, or it can be the result of the Hessian uncertainty being symmetrised without respecting parameter bounds. If the user is sure their model is good, some options are added in this PR to help the fits converge:
1- Use suggested bounds from
pyhf
to force the ranking to cap the value of an NP at its physical limit, independently of the uncertainty extracted from the fit.2- Use the uncertainty from MINOS on the NP which will respect the parameter boundaries by construction.
In this MR, an option to the
fit.ranking
function is added to specify that suggested bounds should be used to set limits on the parameters bounds are not set by user. In addition, the ranking function can now read MINOS uncertainties for relevant parameters if the fit results are provided to it. If the fit results are not provided, the ranking function can now perform the fit itself while allowing the use of MINOS for model parameters.Example spec
The following spec fails even for pre-fit uncertainties.
With this PR the following setups are possible, utilising suggested bounds:
To utilise MINOS, consider the following setup: