Non-intuitive TTree::Draw behavior with array in cut

ROOT
1

Hi all,

I came across some odd behavior trying to call TTree::Draw passing an array variable for the cut. As a very simple example, say I have a tree with the following class in it:

class ChannelData {
   bool is_valid;
};

class Event {
   double energy;
   std::vector<ChannelData> channels;
};

Now let’s say I have a tree with 100 entries, and channels always has 8 elements, and is_valid is always true. If I call

I get a histogram with 100 entries; so far so good. Now I call

tree->Draw("energy","channels[].is_valid"); and I get a histogram with 800 entries, and all the bin heights are multiples of 8. Obviously the draw command is looping over the cut, and adding an entry for each channel entry.

Naively, I expected “channels[].is_valid” to take the AND of all those entries. After thinking some more, I realize that that syntax would be too ambiguous, because some people might assume OR instead (or even something else). I can fake AND behavior by “Min$(channels[].is_valid)==1”, so that’s fine.

However, it’s very unintuitive to me that, if I ask to draw a top-level variable which is not an array, I would get multiple entries for that value each time I pass the cut. I can’t personally think of a reason where this would ever the desired behavior (after all, you should never get more entries by adding cuts!). I think this situation should be at minimum explicitly addressed in the documentation, and additionally present some warning message or possibly even fail if the user tries to draw like this.

Cheers,
~Ben

2

[quote]Naively, I expected “channels[].is_valid” to take the AND of all those entries[/quote]Humm … why ? There is explicitly no correlation between each iteration of the draw. The semantic of TTree::Draw is to do:

for each entry for each array element if ( value_of_cut != 0) htemp->Fill(value_of_expression,value_of_cut)I.e. the cut is actually technically a ‘weight’.

Cheers,
Philippe.

3

Because I didn’t really think about what I was doing =)

My main point, though, was that I think the number of users who WANT to have a single entry filled many times (possibly with different weights, as you point out) is likely to be smaller than the number of people like me who get unexpected results, either by incorrect thinking or not realizing that a cut might be an array, and that having the Draw command spit out some warning message might be helpful.

Thanks for the quick response!
~Ben