Question about definition, naming and correlation of custom modifiers #2595
-
Hello! I'm working on a Belle II analysis that requires custom expressions of modifiers and have been using the branch to be merged in #1991 Another discussion that I have found particularly useful is this one as I'm also using cabinetry to create my model. I've noticed that when defining multiple expressions that should be common among different channels I get the following error I'm pasting below a minimal example to reproduce the error
Of course one can simply use different names for the new modifiers which works without pyhf complaining. However since I'm not sure what exactly happens under the hood it made me wonder whether this is a sub-optimal setup. My current understanding is that, in pyhf, correlation is only guaranteed when modifiers share both the same name and definition. Does using independent names for the custom modifiers -even with identical expressions- lead to pyhf minimizing all these expressions independently from each other even if all of them are functions of the same parameter? Since I cannot build a model where the custom expressions share the same name, I cannot compare results in the two scenarios, therefore I thought of asking the experts here for some insights. If this is the case is there an existing recommended approach for sharing a single custom expression across multiple samples/channels while maintaining correlation, or would this require some changes in #1991? Thanks a lot in advance for the help! Cheers, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hi, when the parameters have different names they should also end up being uncorrelated, I think you would see that |
Beta Was this translation helpful? Give feedback.
Hi, when the parameters have different names they should also end up being uncorrelated, I think you would see that
model.expected_data
now expects an additional parameter to be provided. I am not sure how to accomplish what you are after with the current state of #1991. This also sounds a bit like #2350. One thing that I would suggest looking into is #2579 as an alternative implementation. I do not remember if I have tried doing the same with that newer pull request but I think it would be worth an attempt.