add histogram LGDO

[ManuelHu]

Some open questions:

• this currently has a hard import on the hist package, which could also be a strictly optional dependency. see also Handling package dependencies required by LGDO.view_as() #48
• I added an error message when trying to write a histogram with any wo_mode that might append. I am unsure if this is the nice way to do it...
• For Histogram, not being able to add/remove fields is a hard requirement - otherwise it cannot be read back as a histogram. But overriding all the custom functionality of Struct is not nice. Maybe, having a base class for Struct, but without a clear way for the user to add/remove fields would make sense?
• Should a HistogramAxis accept attrs?
• Should lgdo.types.HistogramAxis be moved to lgdo.types.Histogram.Axis (i.e. as nested type, as the axis type does not make sense as a standalone LGDO?)

fixes #15

[codecov]

Codecov Report

Attention: Patch coverage is 98.13084% with 4 lines in your changes missing coverage. Please review.

Project coverage is 76.26%. Comparing base (5ac36c8) to head (ad9684b).
Report is 100 commits behind head on main.

Files with missing lines	Patch %	Lines
src/lgdo/lh5/_serializers/read/composite.py	91.66%	2 Missing ⚠️
src/lgdo/types/histogram.py	98.90%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #98      +/-   ##
==========================================
+ Coverage   74.45%   76.26%   +1.80%     
==========================================
  Files          45       46       +1     
  Lines        2815     3029     +214     
==========================================
+ Hits         2096     2310     +214     
  Misses        719      719              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gipert]

Looks great Manuel! Some comments:

• we should also support variable-binning histograms
• I would ignore the "problem" with mutable Structs for now
• I think going for lgdo.types.Histogram.Axis is a good idea
• could you document a bit better if data is copied or actually viewed?

@oschulz:

• https://legend-exp.github.io/legend-data-format-specs/dev/hdf5/#Histograms does not mention histograms with variable binning, but should be straightforward to have binedges as an array<1>{real}.
• could you provide an LH5 file with a Histogram object serialized with Julia?

[ManuelHu]

• conversion hist.Hist -> np.ndarray is (mostly) zero-copy
• conversion np.ndarray/Histogram -> hist.Hist (i.e. in view_as("hist") is not just a view, but performs a full copy! Unfortunately there is no way to change it: Initializing histograms from arrays of bin values scikit-hep/boost-histogram#421

[oschulz]

https://legend-exp.github.io/legend-data-format-specs/dev/hdf5/#Histograms does not mention histograms with variable binning, but should be straightforward to have binedges as an array<1>{real}.

Yes, we should absolutely allow that.

could you provide an LH5 file with a Histogram object serialized with Julia?

I'll add a test file to legend-testdata, give me a few days ...

[ManuelHu]

Variable binning works now (with array<1>{real} as binedges). I can also prepare a PR to the data specification in the next days.
There is also some logic that converts an edge array to a range object, if this is possible (i.e. it has a uniform binning). I Am not sure if we want to keep that behavior...

but please do not merge yet, I still have one change in mind. I still want to change one possible parameter type of the binning, as now it is not so nice. -> implemented

[oschulz]

I can also prepare a PR to the data specification in the next days.

Can you also add a test file to the legend-testdata repo via a PR there, so we can test on the Julia side before we merge here and on legend-testdata?

[ManuelHu]

@oschulz see legend-exp/legend-testdata#18
I now uploaded a test file with two 2D histograms, one with range axes, and one with variable binned axes.

[gipert]

This PR seems good to go from my point of view, anything else @ManuelHu?

[ManuelHu]

I also think it is ready, no particularly missing things come to my mind.