feat: Experimental query language support for parameter indexing

[kratsg]

Description

This adds both a pyhf.experimental (sub)module as well as pyhf.experimental.query to support various ways of querying the PDFs.

Documentation is needed. ./cc @alexander-held

Checklist Before Requesting Reviewer

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

Before Merging

For the PR Assignees:

• [x] Summarize commit messages into a comprehensive review of the PR

[codecov[bot]]

Codecov Report

Merging #994 into master will decrease coverage by 0.01%. The diff coverage is 95.23%.

@@            Coverage Diff             @@
##           master     #994      +/-   ##
==========================================
- Coverage   96.65%   96.63%   -0.02%     
==========================================
  Files          59       60       +1     
  Lines        3284     3326      +42     
  Branches      455      466      +11     
==========================================
+ Hits         3174     3214      +40     
- Misses         69       70       +1     
- Partials       41       42       +1     

Flag	Coverage Δ
#unittests	96.63% <95.23%> (-0.02%)	:arrow_down:

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

Impacted Files	Coverage Δ
src/pyhf/utils.py	94.80% <92.00%> (-1.35%)	:arrow_down:
src/pyhf/experimental/query.py	100.00% <100.00%> (ø)

---

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 30dc08a...8c6f317. Read the comment docs.

[alexander-held]

I gave this a try and this feature is extremely useful. It helps a lot with handling the mapping between model.config.par_order and the actual "flattened" parameters expected by pyhf.pdf.Model.expected_data etc., which go into a fit.

[kratsg]

I gave this a try and this feature is extremely useful. It helps a lot with handling the mapping between model.config.par_order and the actual "flattened" parameters expected by pyhf.pdf.Model.expected_data etc., which go into a fit.

can you provide more details on the use case?

[alexander-held]

The main use case I have in mind is holding groups of parameters fixed in the fit. With appropriate naming, I can get for example all indices of parameters called ttbar_modeling_*, which might match everything related to ttbar modeling. From the comparison of the corresponding fit (with those constant) to the nominal fit I can calculate (via quadrature subtraction) the contribution of those parameters to the POI uncertainty.

So far I got the relevant indices by going through model.config.par_order and (given that each entry can correspond to more than one parameter in the fit), had to also consider model.config.param_set(param_name).n_parameters for each parameter.

I just looked at the code in this PR and noticed model.config.par_slice, which I had overlooked before. That already simplifies things quite a bit compared to my current approach.

One other thing that could also be useful is the opposite direction: given an index (within range(model.config.npars)), return the name of the associated parameter. I use that in a few places for logging purpose. The issue there though is that the naming of per-bin parameters like staterror would need to be defined (#867).