csv/root/yoda: add support for underflow/overflow bins

[GraemeWatt]

A long-standing open issue (HEPData/hepdata#358) is to allow open bin boundaries. In the past, this issue was put on hold because it was not clear how to export to ROOT/YODA formats. However, ROOT histograms have an underflow/overflow bin, and explicit underflow/overflow bins are supported by the new YODA2 format, therefore it is now easier to address this issue. I've just made a fix to the HEPData visualisation code to support underflow/overflow bins. The CSV/ROOT/YODA1/YODA2 conversion code should also be adapted to support underflow bins (e.g. {low: -.inf, high: 0}) and overflow bins (e.g. {low: 250, high: .inf}). For objects like ROOT TGraphAsymmErrors and YODA1 Scatter2D that do not support underflow/overflow bins, a workaround would be needed like setting the low/centre/high bin values all to the finite bin limit as in the HEPData visualisation code.

@20DM : maybe you could help with the implementation at least for the YODA2 export?

[20DM]

Hi Graeme - happy to look into this. Is there already an example entry/yaml that I could you for testing?

[GraemeWatt]

Hi Graeme - happy to look into this. Is there already an example entry/yaml that I could you for testing?

Thanks! Here's an example (https://www.hepdata.net/record/sandbox/1707753844) that was reported by a user as not being displayed properly before I made a fix to the JavaScript code. But for testing purposes, it would be better just to construct a minimal example with a few bins where the first bin has "low": -.inf and the last bin has "high": .inf. And make sure that the code works for edge cases like only one open-ended bin etc..

[20DM]

Thanks! I'll have a go at this in the coming days and will make a PR when ready. Can I assume that the HepData uploader will perform some physicality checks like allowing maximally one set of +/-.inf per axis?

[GraemeWatt]

I've just opened an issue (HEPData/hepdata-validator#56) to make a validity check at the upload stage, at least for the case of only one independent variable. For the case of two or more independent variables, at the moment I don't see an easy way to make a validity check, since the variables can be specified in any order. Ideally the converter would be able to accommodate wrong encodings without crashing, i.e. by skipping any bins from the export that don't make sense.