jonas-eschle
commented
4 years ago Hi Eduardo, thanks a lot for the comments! They go very much in the direction of what we already have in mind for the development, I've added some issues to incorporate them explicitly:
There is a lot of interest in being able to publish for example fit likelihoods, e.g. for combinations from several experiments.
This is actually a core design goal (https://github.com/zfit/zfit-development/issues/6). We aim to provide human readable and modifiable representations (and yes, a framework independent specification, as we also aim for with the interface, is the ultimate goal here). It is on the priorities not on the top, as it involves a lot of orthogonal discussions as well, but we will come back to that for sure!
I also commented on what I think is most relevant to expose as the "selling points" of your package, compared to others.
I fully agree! Thanks for bringing that up, I sometimes loose track of the important things :) But I've added it explicitly to the design goals, the focus is exactly on the ease of building etc, not on raw performance.
Coming back to flexibility.
This goes into the same as above, we try to provide the maximum flexibility to do all kind of crazy things while keeping a straight way for the simple cases, basically combining:
-
“We’re all adults here": keep a high flexibility
-
“There should be one – and preferably only one – obvious way to do it": to counter unintentional mistakes that may arise from the above
And yes, this beast are within the goals of zfit with its flexibility
Thank you again for your presentation at the PyHEP WG meeting on Sep. 11th - https://indico.cern.ch/event/834210/. There were various discussions. Let me write down some of the points I raised:
There is a lot of interest in being able to publish for example fit likelihoods, e.g. for combinations from several experiments. This of course implies that one has a good way to represent them. I was suggesting that it would be a game-changer to have a powerful and flexible representation of the whole thing coming out of zfit, so basically the model and fit results. This could ensure one can actually publish "whatever" one wants from a fit, and it also opens the possibility of exchanging models with other fitting packages, which would be great too; think here of what the data science community has with ONNX.
I also commented on what I think is most relevant to expose as the "selling points" of your package, compared to others. Flexibility, correctness and easy writing of very complex models (difficult to write badly, making code slow, for example) are to me major points. Speed is only an issue if the code is significantly slower than what is provided elsewhere. In other words, I do not really care of a factor 2-3, in general. I agree that for users where fitting takes a really long time, any speed improvement is welcome.
Coming back to flexibility. I'm not sure how much you have thought about the modelling typically necessary for time-dependent CP violation analyses. These are beasts of their own, requiring things such as convolutions for incorporation of detector effects, efficiencies multiplying PDFs, flavour tagging. It would be a shame if the framework is not able to deal with these use cases.