scikit-hep
[FEATURE] HistStack
A possible design for stacked histograms is the following:
A HistStack holds multiple histograms; axes are required to match. Calling .plot(...) forwards to mplhep, just like Hist.plot, but with the stack of histograms as a list in the first argument.
To make a stack, you could use |, so that:
(h1 | h2 | h3).plot()
Would make a stack of histograms and plot it.
This also might tie into #165, possibly .interp on a stack would interpolate between histograms? Just a thought.
EDIT: should have added to #34 instead...
@henryiii, just thinking out loud, why a "|" rather than a "&"?
BTW, did you look at some of the functionality that was put into histbook in the past, before it got archived? Stacked histograms were also covered there and one may "steal" ideas from it.
Because it's used in a lot of other places in Python now to mean union, such as sets, dicts (3.9+), and types (3.10+). I believe a "Book" in HistBook was a different thing, a set of different histograms that could be filled together, while this is a set of matching histograms that must have been filled differently. There was a "stack" method, but I think it was just a display style for a single histogram. Good idea to look at HistBook for (other, too) ideas!
FYI: In Python 3.10, int | str is the same as from typing import Union; Union[int, str], and it will work inside isinstance, so you can write isinstance(x, int | str) instead of isinstance(x, (int, str)).
hist.stacks.Stack(h1, h2) would be the explicit constructor. There also should be some way to convert a category axis to a stack. h.stack("axis1") -> stack. The current plot shortcut could be written h.stack("cat1").plot().
For implicit constructor, aka s = h1 | h2 | h3, we probably need to overload __or__ for both Hist and Stack. Hence, IMO, s.push(h4) could be helpful (and s.pop() correspondingly).
I'm thinking 95% of users will likely do h.stack(ax) and not Stack(hist1, hist2, ...), so I'm not that worried about adding a shortcut for it now. If we do, yes, but let's not add it unless we find a strong need for it. Things like #274 are more pressing.