I invite you all to comment on the name
trim
and/or anything else you think about this
(stupid app)
I would prefer a more explicit name for the keyword argument than just two letters. Yes, it's easy to type but also not very descriptive I'm reading it
@jordan-palmer
h[:,a:b:bh.project] is planned, but is dependent on boostorg/histogram#238 at the moment. Once “crop” or whatever it ends up being called is added, it should make this easy to implement.
@daritter It’s actually
, bh=True, nine unaboidable characters already. And, since boost_histogram as bh is the recommend way to use the library, I think it’s not too bad. What would you have instead? bh_object would be more descriptive. object=True (and likewise not prefixing the other bh specific arguments, like storage) would risk colliding with a future numpy release; but the risk there is very low.
(I miss Ruby’s Symbol for something like this)
The hands-on workbook was updated for 0.5.2 today, as well: https://github.com/henryiii/pres-bhandhist - the
.axes usage makes things much nicer.
Outputs are fully rendered, too.
boost::histogram compiles into 53 lines of vectorized assembly code on clang-9 https://godbolt.org/z/632yzE
Also boost::histogram got a new Github frontpage, thanks to all who commented on the new logo! :)
Nice talk from Scott Meyers about CPU caches. Some of it is directly relevant to histograms and why filling a histogram is difficult to parallelize.
https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf
https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf
I am working on extending the mean accumulator in Boost.Histogram to accept more than one sample, so that you can make a profile that compute several means in parallel, like in this example
https://github.com/boostorg/histogram/blob/develop/examples/guide_custom_accumulators_3.cpp
Making it so that it will also work in boost-histogram requires some more thought. The problem in boost-histogram is always that the number of means to compute is only known at run-time, not at compile-time. This changes everything in C++.
https://github.com/boostorg/histogram/blob/develop/examples/guide_custom_accumulators_3.cpp
Making it so that it will also work in boost-histogram requires some more thought. The problem in boost-histogram is always that the number of means to compute is only known at run-time, not at compile-time. This changes everything in C++.
While not very explicilty mentioned, boost-histogram snuck in too:
The discussion was about the stability of being in Boost, so very good!
I think many analysts will use Boost.Histogram indirectly through boost-histogram or hist in the end, so any mention of Boost.Histogram (C++) is also great for boost-histogram.
The ideas discussed in the note are related to efforts of storing the likelihood in a reusable way, see pyhf
One noteworthy point was that they wanted to have histogram which can store arbitrary metadata with each bin. Such a thing is easy to implement with Boost.Histogram.
What's the use case given for per-bin metadata?
@henryiii is this exposed in the python?
Nevertheless, I thought it is cute that you can do something so fancy with boost::histogram, basically effortless
@nsmith- No, this functionality is not exposed to Python. And there is no equivalent functionality to add metadata for each bin of each axis individually, except for the general option to add arbitrary metadata to any axis
you can do this instead:
a = bh.axis.regular(3, 0, 1, metadata=["foo", "bar", "baz"])
It was in a serious draft report on how to preserve the detailed experimental result better, i can send the link tomorrow when i am in the office again