Dear all, I am ready to finish the work on iminuit 2.0. You can see the long list of changes here: https://iminuit.readthedocs.io/en/latest/changelog.html#id2 and you can see the new version in action in the basic tutorial https://github.com/scikit-hep/iminuit/blob/develop/tutorial/basic_tutorial.ipynb (you probably have to reload the page until it actually displays the notebook).
While the list of breaking changes is rather long, some are rather peripheral. I think the highlight is the changed
__init__ of Minuit. Most of the keyword arguments were removed, you now set limits and fix parameters by assigning to the
Minuit.from_array_func was merged with
__init__, e.g. the syntax for a numpy function is
Minuit(np_fcn, (1, 2, 3)) while it remains
Minuit(fcn, a=1, b=2) for a normal function.
Minuit(fcn, 1, 2) now also works.
scanto find a minimum in addition to
from iminuit.v1 import Minuitand get a Minuit object that keeps your old scripts running. It is a significant amount of extra work, because I then also have to carry over the old tests that used the old interface (to make sure it is actually a perfect facade)
iminuit1I would prefer to maintain it all in one repo.
iminuit.v1, that is the TensorFlow solution. But it probably is not worth the effort, and might be better to keep as an option if significant portions of users have trouble with the upgrade, perhaps?
v2.1 is out again with new features (and a few fixes to work again with pyhf). The Minuit object is now copy-able and pickle-able. MINOS can now be called without running MIGRAD first. This means the Minuit object can be now be used as a full error computer even if you use another program to minimize the function (computing HESSE errors without running MIGRAD already worked, now MINOS works too).
Fantastic! Thanks very much for your hard work on this @HDembinski and for being super responsive. We truly appreciate it.
@mayou36 The rewrite with pybind11 gave me the experience to reach deeper in the Minuit2 C++ API to make stuff like this possible. While it was still Cython, the binding code was all a mess and I hated working on it. With pybind11, it is a pleasure.
@matthewfeickert I tried to push a patch upstream to pybind11 regarding the failing torch.Tensor conversion, but it was rejected (with a good reason). It would be nice if torch.Tensor did support the Sequence protocol, but I can also respect the design decision to not do that.
I tried to push a patch upstream to pybind11 regarding the failing torch.Tensor conversion, but it was rejected (with a good reason). It would be nice if torch.Tensor did support the Sequence protocol, but I can also respect the design decision to not do that.
Thanks very much for this effort @HDembinski . Though if pybind11 doesn't want the patch it might be worth us opening up an Issue with PyTorch. They are in general actually quite good, though not as good as JAX but that's very hard, about getting some response to clear and well laid out Issues.
They are in general actually quite good, though not as good as JAX but that's very hard, about getting some response to clear and well laid out Issues.
It is worth a shot, I think! Maybe it was not a conscious decision on their part. You could argue that a numpy.ndarray does support the Sequence protocol, despite being a general "Tensor".