Replies: 2 comments 2 replies
-
|
I spoke too soon. When trying to address specific indices, it fails again: Slicing does work for another file I have though: test.root.zip |
Beta Was this translation helpful? Give feedback.
-
|
Full paths or relative paths are not the issue: what it's trying to do here is load the whole The nested path names (with >>> uproot.open("/mnt/storage/data/misc/Event.root")["T"].arrays(
... ["fTracks.fYfirst[..., :0]"],
... filter_name="event/fTracks/fTracks.fYfirst")
<Array [{'fTracks.fYfirst[..., :0]': [, ... ] type='1000 * {"fTracks.fYfirst[......'>or you could hide that unwieldy field name as an alias (which work just like ROOT's built-in fAliases): >>> uproot.open("/mnt/storage/data/misc/Event.root")["T"].arrays(
... ["first"],
... filter_name="event/fTracks/fTracks.fYfirst",
... aliases={"first": "fTracks.fYfirst[..., :0]"})
<Array [{first: []}, ... {first: []}] type='1000 * {"first": var * float32}'>Also, if you're after just one branch, you can navigate to that branch explicitly and avoid all this searching and renaming. >>> uproot.open("/mnt/storage/data/misc/Event.root")["T/event/fTracks/fTracks.fYfirst"].array()[..., :0]
<Array [[], [], [], [], ... [], [], [], []] type='1000 * var * float32'>Now I'm wondering if you really meant to slice it with " I don't see a bug here, and the above would be good for everybody to know, so I'm going to make this a Discussion. If I'm wrong and there's still a bug, open a new Issue. (Unfortunately, we can't turn Discussions back into Issues, but a second iteration on your problem would likely be more specific, anyway, justifying a new Issue.) |
Beta Was this translation helpful? Give feedback.
-
|
Right, there was a typo there. It should have been Let me explain my use case, and maybe you have a suggestion how to bes implement this: The Now when reading the uprrot3->4 cheat sheet, I saw that the What would you suggest is the best way to load multiple branches (potentially with indices, e.g. to plot the 2nd component of a direction vector) with some sort of filtering based on those (or other) branches? So far I have kept the "provide full path" approach, because some ROOT files might have sub-branches with identical names. |
Beta Was this translation helpful? Give feedback.
-
|
There is no performance gain from using strings (e.g. non-trivial The reason it exists at all is to implement There isn't a way to improve performance beyond reading the arrays used in the cut and the arrays they are meant to cut, then performing that calculation array-wise. TBaskets can't be partially read because they're compressed as a single block, in order to read any byte from a TBasket, you have to read the whole TBasket. There is one caveat: you could do a little better than "read TBaskets into whole arrays, apply cut" by "read individual TBaskets, apply cut to each TBasket-array, then combine TBasket-arrays into whole arrays," which saves a memory copy, but most calculations you might want to do in order to implement the cut are more expensive than a memory-copy. You can still provide the whole path, but it has to be in |
Beta Was this translation helpful? Give feedback.
-
Hello, I am currently testing uproot4 functions with the Histoprint command line tool. In uproot3, one could load branches without specifying the full path. In uproot4 that does not seem to be possible.
This used to work with uproot3. It also does work with uproot4 when explicitly providing the full path to the variable:
Not the additional
/fTracks.Easy to fix by providing the full paths, but I am not sure whether this is expected behaviour.
Beta Was this translation helpful? Give feedback.
All reactions