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:

1. If we implement flow optional argument for ROOT histograms values method, is it compliant with the protocol?
2. Should the plotting protocol be extended to accomodate the flows optional argument in the values 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].