Dispatch GetMinum,GetMaximum calculations to friend when necessary - #22677
Dispatch GetMinum,GetMaximum calculations to friend when necessary#22677vepadulano wants to merge 3 commits into
Conversation
This commit introduces testing for GetMinimum,GetMaximum in case the requested column belongs to a friend tree. Two tests are taken directly from the reproducer reported by a user at https://root-forum.cern.ch/t/ttree-getminimum-getmaximum-only-scan-one-file-of-a-friend-tchain/64905 A third test exercises in particular the correct updating of the branch addresses of the friend TChain when it switches to another file even though the main TChain is still traversing the same file.
Implement a similar strategy to what was done for GetBranch in root-project@30860f3 . This will be used in a later commit to dispatch a call to Get[Minimum,Maximum] to a friend if it has the input column name.
If the input column name belongs to a friend, the methods now dispatch the calculation to the friend itself to ensure the branch/leaf addresses are properly updated.
Test Results 23 files 23 suites 3d 13h 52m 29s ⏱️ For more details on these failures, see this check. Results for commit 9990ddf. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Why this change (treenumber being updated only if a branch is found)? This seems like a significant undocumented behavior change. If I understood correctly:
before: data from all files with the branch will be taking in consideration
after: only the data up to the first file in the chain that does not have the branch will be taken in consideration.
There was a problem hiding this comment.
Do we test for the following odd-ball case:
Chain A:
tree 1 - N entries - branch B. - friend 1 - N Entries - no branch B
tree 2 - M entries - no branch B. - friend 2 - M entries - branch B
tree 3 - O entries - branch B - friend 3 - O entries - no branch B
A (possibly more common) variation of this setup is:
Chain B:
tree 1 - N entries - branch B. - friend 1 - N Entries - no branch B
tree 2 - M entries - no branch B. - friend 2 - M entries - no branch B
tree 3 - O entries - branch B - friend 3 - O entries - no branch B
(and of course one could even play with the friends no being aligned).
There was a problem hiding this comment.
This might be a (not yet) documented behavior change. If I understand correctly, we have:
- before: if there is branch name match in the current tree or any of its friends, check a leaf match in that branch and return.
-
- If no match then do a search through the leaves of the current tree for alternative spelling
-
- If no match repeat over the friends
-
- if no match repeat over the friends with prefix handling
- after: f there is branch name match in only the current tree, check a leaf match in that branch and return.
-
- if no match then do a search through the leaves of the current
-
- If no match then check if branch name match in t any of its friends, check a leaf match in that branch and return
-
- If no match repeat over the friends
-
- if no match repeat over the friends with prefix handling
Fixes #22652