@lnevay Henry already explained it well, yes, you can make histograms which are variable in the number and types of the axes. Please have a look at the docs, which should answer all questions you may have (if not, please drop a note so that I can improve). The Getting Started quick guide has an example here https://www.boost.org/doc/libs/develop/libs/histogram/doc/html/histogram/getting_started.html#histogram.getting_started.3d_histogram_axis_configuration_
Boost.Histogram relys on boost::variant2, so that’s always available; if you are in C++17, you can use std::variant if you prefer.
Henry is not correct here. You need to use the builtin boost::histogram::axis::variant. This is a special variant type with an axis interface. Other variants do not work.
@HDembinski Thanks for sharing. We (my team working with @lnevay ) apparently missed that … In the end we found a workaround by creating a virtual base class implementing an interface similar to what we have already for the (lower) dimensional root histograms, and then a series of concrete classes (templated) for the various axes types.
I believe that, as we have a small number of types so far, this is manageable and there is less overhead.
.fillfaster in the future, while
histogram::callis already as fast as it can be
Tonight I got this warning from
ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts. We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default. tensorflow 2.3.0 requires numpy<1.19.0,>=1.16.0, but you'll have numpy 1.19.1 which is incompatible. tensorflow 2.3.0 requires scipy==1.4.1, but you'll have scipy 1.5.2 which is incompatible.
and from going to read about it on the PyPA's website this is going to be a major change come October. https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-2-2020
This has the potential to be a huge pain.
I mean to quickly detect that something failed.
Me, too. The CAPITAL LETTERS are easy to spot
hey Henry - yep, I have no problem with this display and I am red/green colorblind
Awesome, let’s go with it as is, then!
be a huge pain
Being more strict is generally a little painful at first, but the old behavoir of installing incompatible versions was incorrect, so shouldn’t it be better?
Sorry I was being very brief last night. In general I think that this change is great! I was more selfishly thinking of the fact that TensorFlow is going to force a lower version of SciPy then the one we want to use for
pyhf as the more recent releases benefit from some nice FORTRAN bug fixes