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: Bookkeep fixed parameters #989

Merged
merged 36 commits into from
Aug 2, 2020
Merged

Conversation

kratsg
Copy link
Contributor

@kratsg kratsg commented Jul 26, 2020

Description

This will help with #846 .

The goal of this PR is to:

  • allow for pdf.config.suggested_fixed to provide a list of True/False of parameters which are fixed. This can be essentially stitched with the inits provided by the user, or pdf.config.suggested_init() to get fixed_vals for the optimizer API.
    • tests are added
  • [ ] update the schema (we were idiots) to change fixed to be an array as it needs to be defined for each parameter
    • [ ] tests are added
    • we can additionally allow for a single bool and an array of bools. The single bool could provide backwards compatibility implying all parameters for the modifier are specified as fixed.
  • [ ] update src/pyhf/readxml.py to correctly read in ParamSetting fixed parameters correctly
    • [ ] tests are added
  • [ ] update src/pyhf/writexml.py to write out fixed parameters correctly against the new schema
    • [ ] tests are added

This PR will not propagate fixed parameters from the pdf through to the optimizers. That is the goal of #846.

Help requested:

  • we need examples of HistFactory XMLs that fixed one or two parameters of a given modifier (rather than all of them).
    • decided for now paramsetting will fix all parameters of a given systematic

Bugs identified(?)

  • in src/pyhf/readxml.py, inits suffers a similar bug that fixed does, where the inits for a modifier with n-parameters will be a list of one value.
    • inits (like fixed) will be for all parameters of a systematic

Brain dump:

  • for readxml.py: use re or parse to parse out parameter indices in ParamSetting.text values. I will need an example (see "Help requested") but I assume gamma_stat_SR0L_IStR_cuts[2] would be written into ParamSetting and we need to extract the index of the parameter that such a thing is being configured for (parameter setting) -- and if there is no indexing involved -- this is assumed for all parameters in that modifier (modifier setting).
  • for readxml.py: if we parse out parameter setting, we're going to need to figure out how many parameters the associated modifier has in total (only for: staterror, shapesys, shapefactor) so we can stitch this in appropriately
  • perhaps to preserve backwards compatibility, we can move the complexity out of readxml/writexml and handle parameter parsing inside pdf.py. Instead of trying to go from gamma_stat_SR0L_IStR_cuts[2] to gamma_stat_SR0L_IStR_cuts (or backwards) in read/write XML... we can just write out gamma_stat_SR0L_IStR_cuts[2] as literally the name of the parameter configuration which our JSON is technically for, rather than modifier configuration. As such, every parameter is single-bin -- so the complexity is moved over to trying to reinflate these parameters and inject them into the corresponding modifiers.

ReadTheDocs build: https://pyhf.readthedocs.io/en/feat-bookkeepfixedparameters

Checklist Before Requesting Reviewer

  • Tests are passing
  • "WIP" removed from the title of the pull request
  • Selected an Assignee for the PR to be responsible for the log summary

Before Merging

For the PR Assignees:

  • Summarize commit messages into a comprehensive review of the PR
* Add functionality into _ModelConfig to bookkeep fixed systematics (all parameters for a given systematic)
* Add fixed into tests for paramsets
* Add tests for fixed parameters

@codecov
Copy link

codecov bot commented Jul 26, 2020

Codecov Report

Merging #989 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #989   +/-   ##
=======================================
  Coverage   96.65%   96.66%           
=======================================
  Files          59       59           
  Lines        3287     3294    +7     
  Branches      455      456    +1     
=======================================
+ Hits         3177     3184    +7     
  Misses         69       69           
  Partials       41       41           
Flag Coverage Δ
#unittests 96.66% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/pyhf/modifiers/histosys.py 100.00% <ø> (ø)
src/pyhf/modifiers/lumi.py 100.00% <ø> (ø)
src/pyhf/modifiers/normfactor.py 100.00% <ø> (ø)
src/pyhf/modifiers/normsys.py 100.00% <ø> (ø)
src/pyhf/modifiers/shapefactor.py 100.00% <ø> (ø)
src/pyhf/modifiers/shapesys.py 100.00% <ø> (ø)
src/pyhf/modifiers/staterror.py 96.61% <ø> (ø)
src/pyhf/parameters/utils.py 92.59% <ø> (ø)
src/pyhf/parameters/paramsets.py 100.00% <100.00%> (ø)
src/pyhf/pdf.py 95.93% <100.00%> (+0.08%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5fcf95b...ada372a. Read the comment docs.

@matthewfeickert matthewfeickert changed the title WIP: feat: Bookkeep fixed parameters feat: Bookkeep fixed parameters Jul 27, 2020
@kratsg kratsg force-pushed the feat/bookkeepFixedParameters branch 2 times, most recently from d2958e0 to aa0e894 Compare July 30, 2020 01:49
@kratsg kratsg marked this pull request as ready for review July 30, 2020 02:13
@matthewfeickert matthewfeickert added the tests pytest label Jul 30, 2020
Copy link
Member

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

Looks good. As you said @kratsg, this actually isn't too big, just needing to put these decisions in place. Mostly just a docs fix and then some questions from me but basically good to go.

@kratsg kratsg force-pushed the feat/bookkeepFixedParameters branch from 157a28d to d9f0e4c Compare July 30, 2020 12:16
Copy link
Member

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

LGTM

@lukasheinrich
Copy link
Contributor

LGTM

@lukasheinrich lukasheinrich merged commit 4ef9bfc into master Aug 2, 2020
@lukasheinrich lukasheinrich deleted the feat/bookkeepFixedParameters branch August 2, 2020 08:59
@alexander-held
Copy link
Member

Hi, just gave this a try. I think pdf.config.fixed_pars in the description should mean pdf.config.suggested_fixed(). I wonder whether "suggested" could be misleading, but I guess it depends on whether one views the measurements part of the workspace as a suggestion for how to perform a measurement, or one views the whole workspace as an instruction for doing one specific fit (I personally perceive it more like the second option).

@matthewfeickert
Copy link
Member

Hi, just gave this a try. I think pdf.config.fixed_pars in the description should mean pdf.config.suggested_fixed(). I wonder whether "suggested" could be misleading, but I guess it depends on whether one views the measurements part of the workspace as a suggestion for how to perform a measurement, or one views the whole workspace as an instruction for doing one specific fit (I personally perceive it more like the second option).

@alexander-held Can you open this up as an Issue for us to discuss there (also hopefully making it easier for others to find for future reference)?

@kratsg
Copy link
Contributor Author

kratsg commented Aug 3, 2020

Hi, just gave this a try. I think pdf.config.fixed_pars in the description should mean pdf.config.suggested_fixed()

Fixed.

I wonder whether "suggested" could be misleading, but I guess it depends on whether one views the measurements part of the workspace as a suggestion for how to perform a measurement, or one views the whole workspace as an instruction for doing one specific fit (I personally perceive it more like the second option).

Part of this is to separate out a model definition from a measurement definition. The measurement definitions come into play with suggested_xyz accessors -- as you probably saw (inits, bounds, fixed).

@alexander-held
Copy link
Member

I'll open an issue as suggested by @matthewfeickert, but in the end it's matter of taste what to call it I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat/enhancement New feature or request tests pytest
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants