Conditional Parameters

[hammannr]

This is a copy of #181 (I accidentally merged it and had to revert the main....)
This PR introduces conditional parameters.

What's the problem?

In some cases, we want parameters to take different values depending on the value of other parameters.

One example is the WIMP-mass-dependent signal efficiency uncertainty. Here, we typically have larger uncertainties for lower masses. With conditional parameters, we can now simply add the following to our parameter definition in the config file:

wimp_mass:
    nominal_value: 50
    ...
signal_efficiency:
    conditioning_parameter_name: wimp_mass
    uncertainty:
      5: 0.3
      10: 0.2
      50: 0.15
      100: 0.1
      500: 0.1
    ...

Depending on the value of wimp_mass this will result in a different value of the signal_efficiency uncertainty.

The ConditionalParameter class

Here's an example how the ConditionalParameter class works:

from alea import load_yaml, Parameters


config_path = "%SOMEPATH%/alea/alea/examples/configs/unbinned_wimp_statistical_model_mass_dependent_efficiency.yaml"
config = load_yaml(config_path)

params = Parameters.from_config(config["parameter_definition"])

#  If you directly access a property of the conditional parameter, it will just return the
#  Parameter under nominal conditions (i.e. using the uncertainty for wimp_mass = 50)
print(params.signal_efficiency.uncertainty)
# >>> 0.15

#  The same happens if you call the conditional parameter without any arguments:
print(params.signal_efficiency().uncertainty)
# >>> 0.15

#  If you provide another value though, it will return the parameter for another wimp_mass:
print(params.signal_efficiency(wimp_mass=5).uncertainty)
# >>> 0.3

#  Another way to get there is to change the nominal value of wimp_mass:
params.wimp_mass.nominal_value = 5
print(params.signal_efficiency.uncertainty)
# >>> 0.3

Caveat

So far, this doesn't work "on-the-fly" i.e. if I have a model instance and just change the wimp_mass value it won't correctly update the treatment of the signal efficiency since the likelihood is already initialized with the constraint terms. However, the structure introduced in this PR should allow introducing this feature in the future.

What I tested so far

I tested this in a notebook for a few different WIMP masses (this won't work with the config in alea since we don't have any other WIMP mass templates yet, but you can ask me for an example notebook using actual templates). So far, everything looked good and behaved as expected but heavier testing with large toyMCs will follow.

Please have a look, play around with the new class, and let me know if something unexpected happens. Also, if you have any suggestions on how to implement this better, please let me know! In the meantime, I'll write some unittests and do some first checks with toyMCs.

[coveralls]

Pull Request Test Coverage Report for Build 10278961342

Details

• 75 of 92 (81.52%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.6%) to 91.611%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
alea/parameters.py	75	92	81.52%

Totals
Change from base Build 10265535463:	-0.6%
Covered Lines:	1638
Relevant Lines:	1788

---

💛 - Coveralls

[FaroutYLq]

Thanks Robert for this elegant solution. I didn't run anything but just read through the codes, since you already see it is working and I think the new test is checking the core feature. I think the absence of support for "on-the-fly" doesn't hurt, since we don't expect overriding mass for example in massive production. In notebook, a mistake here won't cost much so I would say we are good to merge now.