Methods for classes embedded in a TTree and splitting

Dear ROOTers,

I find very useful the possibility to create my own classes for data to be embedded in a TTree and the possibility to also call methods of such class for example within a TTree::Draw().
I have several questions around this feature. Let’s assume an example class like this:

class Example
{
   Double_t scalar;
   Int_t n;
   Double_t* array; //[n]
public:
   Example() : n(0), array(0) {};
   Double_t Get(Int_t i) { return array[i]; };
}
  1. So far I have never asked to split such objects, but, as the size of the objects increase, splitting and loading only the needed branches become more and more efficient. If I use on a split object in:

Can the parser guess that the method need a branch data, the branch “array”, to be loaded?

  1. I understood that only methods returning a double can be used in a TTree::Draw(). Have you ever think of (or, have I missed a feature like…) allowing class methods to return a TArrayOfDoublesEspeciallyMadeForThisPurpose, which can be “looped” like a standard array data member?

I mean: the possibility to have TTree::Draw() performing a loop not only over “standard” array variable, but also over especially made arrays that can be returned by a class method.

As usual, thanks a lot!

Matteo

[quote]Can the parser guess that the method need a branch data, the branch “array”, to be loaded? [/quote]At the moment no, the parser of TTreeFormula does not have enough information (it can’t see the content of methods). So in this case, TTree::Draw will always read the full object. However, in this case, you can simply dotree->Draw("myexample.array[2]");which will read only the necessary data (the index and the full array).[quote]Have you ever think of (or, have I missed a feature like…) allowing class methods to return a TArrayOfDoublesEspeciallyMadeForThisPurpose, which can be “looped” like a standard array data member?[/quote]The issue is that it is harder (because of the possible argument) to control the amount of looping necessary. Developing this would requires quite a bit of work/coding which we might tackle once we re-implement the internal of TTreeFormula using cling. In the mean-time for such case, you should consider using the TTree::Draw feature that takes a script as input (and internally use TTree::MakeProxy), you will need to do the looping yourself but will be able to call any of your functions.

Cheers,
Philippe.