183rd ROOT Parallelism, Performance and Programming Model Meeting
UHI for ROOT histograms
DISCUSSION ITEM
- Josh Bendavid: Does h.values() support the
flow=True
optional argument like boost.histogram? - No, the protocol specifies the function does not have arguments
- Presumably if the argument is optional the protocol is still respected, I would implement it as I find it very useful
ACTION:
- If we implement
flow
optional argument for ROOT histogramsvalues
method, is it compliant with the protocol? - Should the plotting protocol be extended to accomodate the
flows
optional argument in thevalues
method?
DISCUSSION ITEM
- Vipul: what if I give a numpy array larger than the entire range including flow bins?
- You get value error
DISCUSSION ITEM
- Jonas Hahnfeld: What happens if we're trying to set a 2D histogram that has only one axis with flow bins but not the other? e.g. a 12x12 (including flows) is the histogram and we have an input (10,12).
ACTION: Investigate what happens in such scenarios where the flow bins can be deactivated. Probably at the moment this can only be tried via boost.histogram
DISCUSSION ITEM
* Josh Bendavid: are the UHI special indexing supported?
* Indexing+ is not supported yet.
DISCUSSION ITEM
* Audience: would be nice to have pretty printing for TH1 at a Python prompt (i.e. Python repr
)
ACTION: Open a github issue to remember this
DISCUSSION ITEM
- Stephan Hageboeck: I am getting different number of entries between an original histogram and its slice. Intuitively, I would expect them to have the same number of total entries.
ACTION: Get a reproducer from Stephan, investigate
DISCUSSION ITEM
- Danilo: when we slice, we are creating a new histogram, with the same name of the original one. Are we sure we're not incurring in potentially dangerous memory management scenarios?
- Silia: UHI slices are always created in isolation, never registered.
DISCUSSION ITEM
* Jakob: when or when not the flow bins are included? It's a bit puzzling
DISCUSSION ITEM
* Josh Bendavid: The values
method for boost.histogram returns a writable view on the underlying array data. I think this is fundamental.
* Vincenzo: To my understanding this is not specified well-enough, so it needs to be discussed. In my opinion, it sounds dangerous.
* Jonas Hahnfeld: I would argue if you call .values
you should always get a copy.
ACTION: Discuss with Henry about the semantics of the return value of values
method. Include in the specification whether this should be an immutable view, a mutable view or a full copy.
DISCUSSION ITEM
* Danilo: this dictionary syntax is a bit terse
* Josh Bendavid: this syntax becomes much more intuitive once you extend the support to Indexing+ and have names for the axes.
DISCUSSION ITEM
* Stephan: The entries in the setting of the TH2 of the second example are too high of a factor 2
ACTION: Investigate and fix
DISCUSSION ITEM
* Audience: we need to understand how the UHI interacts with weighted fills for the indexing protocol.
ACTION: Increase the testing suite with GetBinError
in various scenarios.
DISCUSSION ITEM
* Jonas Hahnfeld: would there be an interest in having some of the UHI functionality not only available from Python but also for C++.
ACTION: Ask Josh Bendavid first, potentially poll a few experts later.
DISCUSSION ITEM
* Oliver: is there a noticeable overhead for the UHI syntax compared to using traditional TH1 methods? Interesting for element access, projections.
ACTION: Introduce microbenchmarks that compare apples-to-apples features of ROOT histograms. One example that comes to mind is ProjectionX
vs h[::sum]
.