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

    Hi all, I got some feedback on iminuit 2.0 and despite my original intentions, I ended up breaking some of the more obscure interface in the overhaul. The opportunity to get a clean slate is just too good to miss for doing a v2.0. I am thinking about how to make the transition more smooth.

    I suppose the most elegant way is to make a last 1.x release, v1.6, in which I deprecate the interface that I haven't deprecated yet but are going to remove in v2.0. Then people can use v1.6 to check what they have to change, since the deprecation warnings will tell them. Makes sense?

    @eduardo-rodrigues @henryiii @jpivarski @matthewfeickert any thoughts?
    Jonas Eschle
    @mayou36
    I fully agree on this! Actually, I nearly wanted to propose this before instead of the beta one to go for a last 1.x release.
    Hans Dembinski
    @HDembinski
    @mayou36 Thank you for the quick feedback! The more I think about it the more I like this solution
    It also means I can break interface in v2.0 without holding back, since I can retroactively deprecate it in 1.6
    That being said, I think I am mostly done breaking things...
    Jonas Eschle
    @mayou36

    It also means I can break interface in v2.0 without holding back, since I can retroactively deprecate it in 1.6

    yes, and I would encourage the breaking and clean interface

    Hans Dembinski
    @HDembinski
    Good to hear :)
    Eduardo Rodrigues
    @eduardo-rodrigues
    Hi. I also fully agree on this. Makes totally sense. It's BTW the kind of move we're making for a final LTS version of several packages on Python 2.7.
    Hans Dembinski
    @HDembinski
    Since we are breaking things, how about removing the latex interface latex_matrix, latex_param, latex_initial_param. I think the functionality can be obtained with the tabulate module and it really has no place in a low level tool like iminuit, I think
    Hans Dembinski
    @HDembinski
    What about this? scikit-hep/iminuit#518
    Hans Dembinski
    @HDembinski
    Eduardo Rodrigues
    @eduardo-rodrigues
    That seems fair, @HDembinski. For Particle I also removed the dependency on tabulate and replaced with to_list and to_dict methods, following your suggestion. I did make sure that the doc(strings) of the latter methods contain nice examples with tabulate such that the reader is straightforwardly helped, as easy-print methods are quite handy.
    Hans Dembinski
    @HDembinski
    @eduardo-rodrigues Adding examples to the docstrings sounds good!
    The advantage of tabulate is that it can generate all kinds of tables, LaTeX, rst, Markdown, you name it...
    Eduardo Rodrigues
    @eduardo-rodrigues
    Yep, I like it a lot. It's also very flexible.
    Hans Dembinski
    @HDembinski

    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.limits and Minuit.fixed properties. 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.

    Not initializing a parameter is now an error.
    The new version can use simplex and scan to find a minimum in addition to migrad.
    iminuit now has 100 % test coverage, too.
    Hans Dembinski
    @HDembinski
    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.
    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
    @mayou36
    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.