Bug in TTree::Draw()?

ROOT
1

Hi,

I observed strange behavior in the TTree:Draw() function today. I could reproduce it in ROOT 5.34/14, 5.34/18, as well as 6.02/05.

The problem is shown easily with the attached file. It contains 1 event with several branches of type std::vector, among others. I am trying to plot two of these branches, ValRecTausPhi and ValMCtausPhi, against each other, but I find that the result depends on which branch goes first:

[code]$ root -l DrawProblem.root
root [0]
Attaching file DrawProblem.root as _file0…
root [1] treeR->Scan(“ValRecTausPhi:ValMCtausPhi”)

  • Row * Instance * ValRecTau * ValMCtaus *
  •    0 *        0 * -0.334601 * -0.370766 *

  •    0 *        1 *           * 0.8069651 *

(Long64_t)2
root [2] treeR->Draw(“ValRecTausPhi:ValMCtausPhi”, “”)
Info in TCanvas::MakeDefCanvas: created default TCanvas with name c1
(Long64_t)2

// NOTE that we got 2 entries

root [3] treeR->Scan(“ValMCtausPhi:ValRecTausPhi”)

  • Row * Instance * ValMCtaus * ValRecTau *
  •    0 *        0 * -0.370766 * -0.334601 *

  •    0 *        1 * 0.8069651 *           *

(Long64_t)2
root [4] treeR->Draw(“ValMCtausPhi:ValRecTausPhi”, “”)
(Long64_t)1

// NOTE that we got 1 entry only
[/code]

If I understand the ROOT documentation correctly, the second Draw result (1 entry) is right, and the first result (2 entries) is wrong, because the Draw loop should only iterate over pairs that are in both lists, and stop looping after “min(length1, length2)” iterations. (Search “So the loop equivalent” in root.cern.ch/root/html/TTree.html#TTree:Draw@2)

Furthermore, it would be really counterintuitive if a scatter plot depended on the order of the axes.

Still, it’s possible that I simply don’t understand things right. What do you think?

Thanks,
Peter
DrawProblem.root (49 KB)

2

My 5 cents.
I agree that the TTree::Draw (and related methods, e.g. TTree::Project) should support variable sizes for multi-dimensional arrays (i.e. ALL DIMENSIONS should be checked for each entry of the tree).
It seems to me, however, that this is not really the case now.
First, all examples marked as “loop equivalent” use FIXED SIZE arrays only (note that, currently, the TTree::Branch method supports only 1-dimensional variable size arrays, while 2-dimensional arrays are always fixed size).
Then, in an earlier paragraph, one can find:
"For variable size arrays (and TClonesArray) the range of the FIRST DIMENSION is recalculated for each entry of the tree."
So, I assume that if you can guarantee that the LAST VARIABLE in your expression is always the “shortest” one, then you’ll get the “correct” result.

3

Hi Wile,

Thanks for your comment. However, I do not have multi-dimensional arrays; my branches are std::vector which is one-dimensional. I do have multiple such one-dimensional branches.

So, if the range of the first dimension is recalculated for each entry, then the behavior that I observed should not occur. (The treatment of higher dimensions does not concern this issue.)

Is this a ROOT bug, or am I getting something wrong?

Best,
Peter

4

Actually, I think the “FIRST DIMENSION” behavior is what you really get.
The “ValRecTausPhi” length is 1, while the “ValMCtausPhi” length is 2. So, if you draw “ValMCtausPhi:ValRecTausPhi”, you get 1 entry, while if your draw “ValRecTausPhi:ValMCtausPhi”, you get 2 entries.

5

This is a terminology question. Is the “first” dimension (whose range is recalculated) supposed to be

  • the first dimension of the output histogram?
  • the first dimension of the branch in question, if it is a multi-dimensional array?

I am pretty certain that it is the latter. Just search for “on both 1st dimensions” in root.cern.ch/root/html/TTree.html#TTree:Draw@2 and you’ll find an example from the description of how ROOT loops over arrays that shows the first dimension of the array is meant.

Furthermore, there is another reason why I disagree: The problem does not occur if the length of ValRecTausPhi is 2 and the length of ValMCtausPhi is 3. I can select ValRecTausPhi:ValMCtausPhi or ValMCtausPhi:ValRecTausPhi and will get 2 entries in the histogram in both cases.

If there are no further ideas, I think it’s time to report this in the bugtracker. Thanks for your help anyways.

6

bug report: sft.its.cern.ch/jira/browse/ROOT-7260