Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Henry Schreiner
    @henryiii
    This Gitter is mostly a few dedicated poeple (mostly devs), and while gitter has threaded convos, nobody really uses them. And there’s no reasonable search. It’s rather useful for announcements, but it’s taking off for the type of help discussions I would have hoped to see. Pybind11 is a great example of a vibrant Gitter community - but there, the same set of questions tend to get asked over and over.
    Alexander Held
    @alexander-held
    Oh, is it possible to move an issue over to make it a discussion instead? That is very nice.
    Henry Schreiner
    @henryiii
    Yep, a ton of Awkward issues got moved over. And a few Uproot ones. You can even move them by label. :) Also, you can move them to a different repo if they were opened in yours but really were for a library higher up the chain.
    Alexander Held
    @alexander-held
    This is really useful, I like that a lot.
    Henry Schreiner
    @henryiii
    Imagine someone opens a feature request (called Ideas) discussion in boost-histogram. It’s for something we don’t think is basic/universal enough for boost-histogram, so we move it to Hist. :)
    Hans Dembinski
    @HDembinski

    What is that one place you describe, gitter? To me gitter does not seem suited for focused discussions - the history is hard to read, even more so when one comes back after a month and tries to find a topic discussed previously.

    Yes, I was referring to Gitter as the place to communicate with users.

    Alexander Held
    @alexander-held
    I see usefulness in both Gitter and GH Discussions:
    • Gitter for issues that require some back-and-fourth for a short amount of time and are likely very user-specific (e.g.: my compilation fails and I don't know how to fix it), if that gets lost in the history it is probably ok since other users may not have the same question
    • Discussions for questions that lots of users may have (and then in the future find there answered, like StackOverflow), or questions that take a long time to answer (to have one consistent thread there instead of being spread out in Gitter between other topics). I also think the "Show and tell" category could be quite nice, and a message like that would disappear quickly in Gitter. And I personally like the idea of everything in one place (repository) a lot.
    Henry Schreiner
    @henryiii
    I’d see gitter as more for announcements and for developer discussions (scroll back in the history, it’s pretty much the same 4-5 people with maybe a couple of user questions), while most users usually open an issue (there are more question issues than questions in gitter, I believe). Discussions gives them a safer, nicer place to open these things that hopefully won’t be as large of a barier, and will be more discoverable after they are answered. But they should be seen mostly as better orginization and a few extra features like threads and answers on top of issues.
    Andrzej Novak
    @andrzejnovak
    I haven't had the chance to use discussions much in mplhep yet, pretty quiet these days, but I am a big supporter. It's a great place for "not quite issue"'s. Gitter still works when one has a question that's more random, but it might as well not keep history past few days
    Henry Schreiner
    @henryiii
    With gitter you also tend to “subscribe” to the whole thing, rather than just quickly ask a single question and follow just that.
    Hans Dembinski
    @HDembinski
    Fine, what I am not interested in is proliferation of places that I have to check for user feedback.
    Jim Pivarski
    @jpivarski
    I set them all up with email notifications. That way, I don't have to explicitly remember to check.
    Hans Dembinski
    @HDembinski
    @jpivarski That's good advice, thanks
    Michael Eliachevitch
    @meliache
    Hi. Thanks for the cool package, I am trying to use it for my new plots. Is there any canoncial/convenient way to do stacked histogram plots, similar to plt.histogram(stacked=True)? So far I just used that to plot my boost histograms:
    image.png
    Michael Eliachevitch
    @meliache

    My histogram is having a Regular and a strCategory axis and I want to show the cumulative sum of the categories, but with the different components stacked on top of each other.

    I found out I can just use np.cumsum(axis=<category axis>) to calculate the cumulative sum and create a new histogram from that. In had also managed to draw a stacked histogram by plotting multiple plt.bar with different bottom=... arguments taken from the cumulative sums. But I dislike that visualy, because I want to have a black outline for my components, but no outlines for the individual bins, as seen in the screenshot.

    Andrzej Novak
    @andrzejnovak
    @meliache you could check if the mplhep.histplot works for you it should handle stacking reasonably
    though admittedly i have not tested is super thoroughly with bh, but as especially if exported to numpy arrays it should be trivial to plot stuff like this
    Henry Schreiner
    @henryiii
    This is going to be something I’ll make sure works in the near future - propagating the Protocol so we can easily plot weighted histograms is my main priority currently.
    (And the correct way to do it will be the function in mplhep, or possibly mpl’s new stairs plot)
    Andrzej Novak
    @andrzejnovak
    @henryiii I have it on the list to implement it in mplhep, but I am waiting form mpl 3.4 with stairs
    Will probably bump minor version for mplhep with it
    Alexander Held
    @alexander-held

    Hi, I used to be able to modify histogram contents like this

    import boost_histogram as bh
    import numpy as np
    
    bins = [0, 1, 2]
    hist = bh.Histogram(bh.axis.Variable(bins), storage=bh.storage.Weight())
    yields = [3, 4]
    var = [0.1, 0.2]
    hist[...] = np.stack([yields, var], axis=-1)
    
    hist.view().value /= 2

    That worked until boost-histogram version 0.11.1. In the current master it does not anymore, I think scikit-hep/boost-histogram#475 changes the behavior:

    Traceback (most recent call last):
      File "test.py", line 10, in <module>
        hist.view().value /= 2
      File "[...]/boost_histogram/_internal/view.py", line 57, in fset
        self[name] = value
      File "[...]/boost_histogram/_internal/view.py", line 49, in __setitem__
        raise ValueError("Needs matching ndarray or n+1 dim array")
    ValueError: Needs matching ndarray or n+1 dim array

    Is there another way to achieve this now?

    Henry Schreiner
    @henryiii
    That’s supposed to work, it’s just been generalized to work in more places - must be a bug!
    Alexander Held
    @alexander-held
    Thanks! I'll open it in an issue then.
    Henry Schreiner
    @henryiii
    Perfect, thanks, I’ll get right on it.
    Henry Schreiner
    @henryiii
    Ahh, the breakage happens with the final line, not the earlier part. Good, faith in my testing has been restored. I was sure I tested somethign like the hist[…] line. Okay, interesting; this code wasn’t supposed to have triggered here. Working on fixing now.
    Technically, this is still “unimplemented” behavior - see scikit-hep/boost-histogram#276 - but if it used to happen to work, it should continue to. And it was planned anyway. Sorry, thought you were using hist.view() /= 2.
    Henry Schreiner
    @henryiii
    Found the bug. 🤦
    Henry Schreiner
    @henryiii
    Static typing would have caught this. (Even just by forcing me to be aware of the possible arguments to __setitem__)
    Alexander Held
    @alexander-held
    Thanks a lot Henry!
    Henry Schreiner
    @henryiii
    Boost-histogram 0.12 is out. It’s mostly a bugfix release, fixing several important bugs, with a few minor things. The current develop branch has PlottableProtocol, which needs a little more time before being released, but feel free to try it out if you like the bleeding edge!
    Hans Dembinski
    @HDembinski
    :-D
    Hans Dembinski
    @HDembinski
    Hi all, there is currently a push in scipy to include Boost as a dependency. This is initiated by the wish to replace current implementations in scipy.special and scipy.stats with those in Boost.Math. Someone else (not me!) then brought up that one could then also base histograms and the scipy.stats.binned_statistics on Boost.Histogram.
    I then told them about boost-histogram and the possible performance increases. Not anything I could work on anytime soon, but exciting to see interest in Scipy about this sort of thing.
    Someone also mentioned the problem with incremental filling, which is currently not efficiently possible with numpy.histogram, which boost-histogram solves.
    I was told that scipy.stats.binned_statistics is a pure python implementation currently, so basing it on Boost.Histogram would surely speed up that code.
    Jim Pivarski
    @jpivarski
    Cool! I hope that happens! Might that mean that boost-histogram (the Python interface) would become part of SciPy? That would strongly serve to standardize histogramming in Python.
    Hans Dembinski
    @HDembinski
    It does not seem impossible
    Eduardo Rodrigues
    @eduardo-rodrigues
    Excellent news @HDembinski! Looking forward to further news on that front.
    Henry Schreiner
    @henryiii
    Sorry, currently, it is impossible. Boost.Histogram requires C++14, and SciPy ships manylinux1 wheels. You can’t build the C++14 code in Boost.Histogram with GCC 4.8.2. However, the PyPA plans to drop manylinux1 this summer, so at some point this year, in theory, SciPy/NumPy/etc. will all stop shipping manylinux1 wheels, and suddely the minimum compiler anyone cares about will be much higher (8.3.1 for manylinux2010), making this possible for the first time!
    It’s going to be a big deal, because pip 9 can’t download manylinux2010 wheels, which is the main reason they still ship manylinux1 wheels today. And recently I found if you use Ubuntu 18.04, and use the python-3.8 package, you still get pip 9 even on Python 3.8!!! (which is totally unsupported). I hate distro packaging sometimes…
    Henry Schreiner
    @henryiii
    NumPy has already taken the first baby step by dropping the manylinux1 wheel for Python 3.9
    Hans Dembinski
    @HDembinski
    Good point, Henry, but I think that this is not something to happen on a short time-scale anyway
    They are currently debating whether they want to depend on Boost at all (although this seems to have some support...)
    Boost.Histogram was only brought up because Boost.Math is so intertwined with other Boost libs that it is not feasible to extract only Boost.Math, they then have to depend on all of Boost anyway.
    Interestingly, the point about C++14 may also come up when they start to use Boost.Math. The implementations in Boost.Math depend on varying versions of the C++ standard, because the maintainers leave it to the contributors which standard they prefer (which is not the best idea IMHO)
    Henry Schreiner
    @henryiii
    The PlottableHistogram Protocol is now released in boost-histogram 0.13.0, hist 2.1.0, uproot 4, and mplhep 0.2.16!
    Henry Schreiner
    @henryiii
    Good bye, Python 2.7 and 3.5! scikit-hep/boost-histogram#512 :tada:
    Matthew Feickert
    @matthewfeickert
    Nice! Congrats @henryiii and @HDembinski!