Model parameter index for components of non-scalar parameters

[alexander-held]

Summary

With the addition of model.config.par_names, there is a well-defined name for components of non-scalar parameters available within pyhf. It would be useful if model.config.par_slice would support parameter indexing to access components of non-scalar parameters. At the moment it will return the slice of all components, and return a KeyError when using it with the name of a component.

This can be worked around (example utility in cabinetry: model_utils._parameter_index), but it would be convenient to support this in the pyhf API.

related:

• Add additional Model helper methods #1235
• possible future addition: feat: Experimental query language support for parameter indexing #994
• changes to support model.config.par_names:
  • Obtaining fit parameter labels #867
  • feat: Propagate model parameter names to optimizers #1536
  • feat: par_names handles non-scalar modifiers with 1 parameter #1560

Additional Information

Example usage for a model with multiple bins for a channel and staterror modifier

model: pyhf.pdf.Model
model.config.par_names()  # ['mu', 'staterror_SR[0]', 'staterror_SR[1]', 'staterror_SR[2]', 'staterror_SR[3]'] 
model.config.par_slice("staterror_SR")  # returns e.g. slice(1, 5, None)
model.config.par_slice("staterror_SR[0]")  # KeyError: 'staterror_SR[0]'

Code of Conduct

• I agree to follow the Code of Conduct

[lukasheinrich]

would you say

model.config.par_slice("staterror_Signal_region[0]") is better than

model.config.par_slice("staterror_SR")[0] is bette thann

and if so .. should we also allow slices?

model.config.par_slice("staterror_Signal_region[0:2]")

[alexander-held]

Sorry for the possible confusion about staterror_Signal_region vs staterror_SR, that was just because I copied this from an example and then forgot to change it in one instance. I edited the example above.

Regarding model.config.par_slice("staterror_SR[0]") vs model.config.par_slice("staterror_SR")[0]: I find the "staterror_SR[0]" version much more useful, because this is the name used in par_names. It is the name under which parameters are known to users, and splitting the [0] out makes this less convenient to work with in my opinion.

For the slicing: I would say why not. I do not have a concrete use case for this in mind, but it seems like it could become useful as well. The main use case I am thinking of is to get slices for single parameters to modify them separately, e.g. to set them to constant for a NLL scan.

[kratsg]

Partially implemented in #994 no?

[alexander-held]

As far as I remember, yes #994 allows for this too. I opened this issue because I think it makes sense to have it in the model.config.par_slice API directly instead of just in the pyhf.experimental API. I would say that

model.config.par_slice("staterror_SR[0]")  # KeyError: 'staterror_SR[0]

not working could almost be viewed as a bug, since par_names is perfectly happy to provide that name.

[kratsg]

I think arguably, if you want to support that, we could have experimental query language support plugged in, so that the par_slice can delegate to the query language functionality...