TGraph not supported

[beojan]

While uproot4 supports TGraphAsymmErrors, it seems plain TGraph isn't supported.

[jpivarski]

"Support" in this case means, "has special high-level methods for easier access." All of the data can be accessed as all_members (dict) and member (method to access one).

TGraphAsymmErrors has these high-level methods because @kratsg had an idea about how he wanted to access TGraphAsymmErrors and implemented it (#240). The equivalent for TGraph would probably be very similar: a values property without the errors.

It's enough to add a submodule with the class name containing a class of the same name in uproot.behaviors, similar to

https://github.com/scikit-hep/uproot4/blob/main/uproot/behaviors/TGraphAsymmErrors.py

Since there are (to a first approximation) infinitely many classes in ROOT and the automated interpretation gets all of the private data members into all_members, I'd like to encourage users of Uproot to define how they want to access their favorite classes. That's why "uproot-methods" used to be a separate module (so that it could change more rapidly than the main codebase, and demonstrably didn't break core functioning), but keeping it as a separate module led to it getting ignored and out-of-date. So the methods/behaviors are part of the main Uproot codebase again, but I'd still like users of these classes to take an active part in shaping them.

[kratsg]

I did implement being able to read memberwise versions of TGraph recently in #298 . I think until that point, it wasn't quite easy for one to be able to read it in. One could use the test file in scikit-hep to write a test for it. I'm guessing because it's a TGraph, you'd only want the x/y values and not much else?

[beojan]

In my case I'm actually reading a RooCurve. I'll work on a PR for this, the RooCurve could use some extra functions to disentangle the strange way RooFit plots histograms and errors on histograms.

[jpivarski]

Wait, are we talking about deserializing (to get an object at all) or accessing the object's methods in an easier way? Deserialization is a more significant effort (and @kratsg's work on memberwise deserialization is beyond what I'd expect most people to be able to do).

I thought we were talking about the fact that there's a TGraphAsymmErrors submodule in uproot.behaviors but not a TGraph.

[beojan]

I was talking about the behaviour. I can see that we have a filled all_members already.

[kratsg]

Well, I believe up until that PR -- most TGraphs were not able to be read in since it seems a lot of them tend to be memberwise-serialized. Now that they can be read in, it shouldn't be too hard to add in the behavior. Just mostly explaining why the behavior never quite existed before for a common object.

[jpivarski]

Well, "most" depends on what kinds of ROOT files you tend to look at (i.e. the measure of your space). I remember that uproot-methods had a behavior defined for TGraph, indicating that Uproot 3 could access TGraphs, even though Uproot 3 didn't do any memberwise deserialization.

It was scikit-hep/uproot3-methods#7, added by @marinang. Looking at that now, I see that there's actually three classes, TGraph, TGraphErrors, and TGraphAsymmErrors. His implementation had a lot of methods for finding the maximum and such, though I'd rather have these objects have smaller interfaces that go straight to the library with all of that functionality now. That is, with a values method to get a NumPy array, things like the maximum can be computed in NumPy. There was also a matplotlib method; it wouldn't be bad to have something that immediately returns an "ax" to be mixed into a plot or implicitly drawn by Jupyter.

Actually, TGraph and TGraphErrors are the only two behaviors that haven't been reimplemented in Uproot 4 or are going to be in Vector. That set—histograms/profiles, graphs, TParameter, and 2D/3D/Lorentz vectors—are the ones that are desirable enough that they were requested again after the Uproot 3 → 4 transition. THnSparse is in the old uproot3-methods/classes directory, but it's just a placeholder (says "hello world") as an illustration of how to get started.

[beojan]

I've made a PR here with a draft implementation. No tests yet, I think those need to go in scikit-hep-testdata, right?

[jpivarski]

@beojan Thank you!

Any files that are needed as input to a test would have to go into scikit-hep-testdata/src/skhep_testdata/data, which has a normal PR/release process. If you have any files that you plan to use to test #350, you can make the PR now and I'll merge-and-deploy scikit-hep-testdata as soon as possible. It should be publicly sharable and not much larger than a megabyte. (The largest so far is 64 MB, but the median is 68 kB.)