fix: ak.unzip visits all contents

[agoose77]

This fixes #2372 by arresting recursion at the first record or union. I think this was the original intention, but the codebase was in a lot of flux at this point, and so it was likely missed.

Note that, in #2372 there are additional cases below the unzip that might also need addressing. We should raise these as new bugs.

[agoose77]

Huh, hold on a moment, this no longer fixes things for me. Perhaps I regressed something ...

[codecov]

Codecov Report

Merging #2373 (5f8ac2e) into main (01417bc) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/operations/ak_unzip.py	95.83% <100.00%> (-0.33%)	⬇️

[agoose77]

Ah, of course, we None is treated as an implicit recursion. Fixed!

[jpivarski]

Okay, good!

I thought I'd checked ak.unzip as a possible culprit. Is this the only one, or are there any errors left in #2372 after this?

If this is it, then the test case on #2372 can become a unit test here.

[jpivarski]

That was supposed to be an approve. (Though the test should be added, if it can be.)

[lgray]

Let me check it with a full nanoevents form.

[lgray]

Even for my repro this branch doesn't fix the over-touching.

[lgray]

Ah, excuse me, it has fixed part of it:

(coffea-dev) lgray@Lindseys-MBP awkward % python -i ../coffea/form_madness.py      
ab>>> ['muon_list!', 'jet_list!'] 

dr>>>> ['muon_list!', 'jet_list!', 'muon_eta!', 'jet_eta!', 'muon_phi!', 'jet_phi!'] 

mmin>> ['muon_list!', 'jet_list!', 'muon_eta!', 'jet_eta!', 'muon_phi!', 'jet_phi!'] 

pt>>>> ['muon_list!', 'jet_list!', 'muon_eta!', 'jet_eta!', 'muon_phi!', 'jet_phi!', 'jet_pt!', 'jet_crossref_index!', 'jet_crossref_content!', 'jet_thing1!'] 

It doesn't touch the "crossref"s any more at an early stage but still touches all the jet fields.
I suppose this is what is meant by "cases below unzip".
Let me see if I can back-out unzip and still get the problem.

[agoose77]

It doesn't touch the "crossref"s any more at an early stage but still touches all the jet fields.
I suppose this is what is meant by "cases below unzip".
Let me see if I can back-out unzip and still get the problem.

Yes, I'm not super familiar with the purpose yet, but I can see that I wouldn't expect these cases to touch these buffers.

[lgray]

If you mean the purpose of the "crossref", it could could be any name, the purpose is sort of aside the point. I could call it "cheeseburger" and it would still overtouch the data (so long as cheeseburger is a ListOffsetArray) when I index after a cartesian.

[agoose77]

If you mean the purpose of the "crossref", it could could be any name, the purpose is sort of aside the point. I could call it "cheeseburger" and it would still overtouch the data (so long as cheeseburger is a ListOffsetArray) when I index after a cartesian.

No, you're fine there! It's really that I don't understand the details of nanoevents just yet, at least, not as a user.

[lgray]

Ah, that has to do with the oral tradition of how CMS/ATLAS HEP physicists are trained to think about their data. It is highly object oriented and full of relational linkages (leading to lots of structure and arrays that are indexers of other arrays in awkward). It's a pretty decent way to think about the data, and maybe we can improve that with time, but it is hard to tell people to change the way they think in more than one direction at once (and moving to awkward array is already a big jump).

Nanoevents accomplishes this by taking columns following a naming convention in some file format (which is usually collections of flat or singly jagged arrays in root files with a particular naming convention) and generating the form (with appropriate form keys to the original arrays) that uses the structure and relationships possible in awkward array to expose the structured / relational nature of collider physics data. The details I think you're wondering about are probably mostly related to cross-cleaning of physics objects and relationships of jets to constituents and such.

The implementation details are mostly @nsmith-, if you want to dig very deep.