Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Hans Dembinski
    @HDembinski
    The new version can use simplex and scan to find a minimum in addition to migrad.
    iminuit now has 100 % test coverage, too.
    I gave up on making a special version of the v1.x to deprecate the interface that was removed in v2.0. I rather put my energy in the changelog.
    Hans Dembinski
    @HDembinski
    I will wait a week for feedback, in case any red flag pops up that I missed. I plan to release iminuit-2.0 on December 7th.
    Hans Dembinski
    @HDembinski
    @mayou36 I think I can lift the technical restriction now that did not allow one to run minos() starting from an arbitrary point.
    1 reply
    Hans Dembinski
    @HDembinski
    Different topic: I recently got an email from Glen Cowan with some questions about iminuit. He wants to use it for teaching, which would help greatly with iminuit's popularity, given how famous Glen is as a statistics lecturer.
    1 reply
    The exchange with him reminded me how important it is to have stable interfaces for such elemental tools, so that third-party teaching material (which typically is not updated very frequently) does not get outdated
    The plan is to keep the interface stable throughout the 2.x series.
    Henry Schreiner
    @henryiii
    Haven’t looked into it in detail, but the changelog looks fantastic! Great job!
    1 reply
    Jonas Eschle
    @jonas-eschle
    The changelog looks extensive yet exactly like the breaks that should be there for the future
    Why exactly the slots though?
    6 replies
    Eduardo Rodrigues
    @eduardo-rodrigues
    Indeed an impressive changelog and series of improvements! Thumbs up!
    That's excellent news to hear the interest from Glen Cowan! Good luck there.
    Hans Dembinski
    @HDembinski
    If you want to give the wheels a spin, pip install -i https://test.pypi.org/simple/ iminuit==2.0rc1
    Wheels from 3.6 to 3.9 are available
    By the way, I was not aware that if you add "rcX" to your version, it is marked on PyPI as a prerelease that is not automatically installed by pip as the "latest" version
    So far I was publishing the betas and prereleases on test.pypi.org, but with this feature I can just use normal pypi.org
    Hans Dembinski
    @HDembinski
    Hi, almost ready for the v2.0 release, I just have to make one last decision. After seeing the email from Glen and also after stumbling again over Jim's note on pyminuit (which apparently still some people want to use), I wonder whether I really should keep the old interface alive somewhere in v2.0. External teaching material can lag very much behind the current iminuit release. At some (distant) point in the future the compatible version v1.x of iminuit will stop working, so I cannot just say "use v1.x" forever.
    Jim Pivarski
    @jpivarski
    Those users who are stuck on the old interface—can't they pin to iminuit<2.0?
    Hans Dembinski
    @HDembinski
    I could reimplement the old interface in v2.0 in a separate object that is just a facade over the current Minuit object, so you can do from iminuit.v1 import Minuit and 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)
    Jim Pivarski
    @jpivarski
    If people need to use both the old and new interfaces (which was necessary for Awkward and Uproot, though I don't see why it would be so for iminuit), then the version 1 can be sent to another PyPI package, iminuit1, for import iminuit1 as iminuit.
    Hans Dembinski
    @HDembinski
    @jpivarski Yes, they could for now, but at some point the binary wheels will stop working, when CPython has moved beyond 3.8 (currently the most recent version that I build wheels for). I could try to keep the wheels for v1.x alive in the future, but that also has costs
    Regarding iminuit1 I would prefer to maintain it all in one repo.
    2 replies
    Sorry, my previous comment was an answer to your previous comment
    Jim Pivarski
    @jpivarski
    @HDembinski If they're stuck on an old interface, aren't they also stuck on old infrastructure? Sure, iminuit<2.0 and Python 3.12 may be incompatible, but is anyone wanting that combination, rather than iminuit<2.0 and Python 3.6?
    Hans Dembinski
    @HDembinski
    That is a good point..
    You are right.
    Henry Schreiner
    @henryiii
    (This is basically NumPy’s reasoning behind NEP 29, I think)
    If it is easy to make 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?
    Hans Dembinski
    @HDembinski
    @jpivarski @henryiii Thank you for the input, I now see that my worries are unfounded.
    Hans Dembinski
    @HDembinski
    :star2: iminuit 2.0 is now released and available on PyPI :star2:
    Jim Pivarski
    @jpivarski
    I cross-posted on IRIS-HEP Slack. :)
    Hans Dembinski
    @HDembinski
    Thank you @jpivarski :)
    Hans Dembinski
    @HDembinski
    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).
    Jonas Eschle
    @jonas-eschle
    Amazing, these are great new features!
    Matthew Feickert
    @matthewfeickert

    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.

    Hans Dembinski
    @HDembinski

    @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.

    Matthew Feickert
    @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.

    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.

    Henry Schreiner
    @henryiii

    Cython, the binding code was all a mess and I hated working on it. With pybind11, it is a pleasure.

    +1!!!

    Matthew Feickert
    @matthewfeickert
    I gotta try out pybind11 sometime this break. :)
    Jim Pivarski
    @jpivarski
    +1 from me, too: I've tried Cython and pybind11, and the latter is much more maintainable. It's not just the coding style when using it, it's the fact that Cython requires much more tooling, which is usually not available in the first weeks or months after a new Python version comes out. It's usually not the case that one technology is better than another in all ways, but this one seems to be.
    Henry Schreiner
    @henryiii
    They are not 1:1. Pybind11 is a tool for making Python bindings to C++ libraries - exactly what we need in these cases. Cython is a Frankenstien’s monster that was built to allow Python to be compiled (AOT Numba, basically), that just happened, due to the design, allow Python bindings to C and (with a toggle) C++ libraries. But that’s not at all what it was designed for originally.
    Now SWIG is 1:1, and there the fact pybind11 doesn’t need tooling is a huge plus. And the all-or-nothing approach of SWIG is a nightmare for any non-tiny library.
    Hans Dembinski
    @HDembinski

    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".

    If you open an issue, I can chime in.
    The main issue with Cython (apart from the fact that you have to learn a hybrid language of Python and C) is that it was not designed for C++. For C code it probably does a good job (although I would still prefer pybind11 even for C code). For C++, you have to work around its (severe) limitations.
    Hans Dembinski
    @HDembinski
    The fact that pybind11 is just C++ so you don't need another compiler/code generator is also a plus, agreed.
    Matthew Feickert
    @matthewfeickert
    Congrats on the new release @HDembinski! :D
    Hans Dembinski
    @HDembinski
    Thanks :) Were you waiting for that fix?
    Do people here have thoughts on scikit-hep/iminuit#654 ?
    Matthew Feickert
    @matthewfeickert
    no, not waiting for the fix, just always nice to see new releases from people. :)