Re: [ROOT] tree splitting

From: Susan Kasahara (schubert@physics.umn.edu)
Date: Tue Apr 24 2001 - 18:01:14 MEST


Hi Phillipe and Rene,
Thank you,  I look forward to trying out the new selection mechanisms
when they appear in CVS.
-Sue

Rene Brun wrote:

> Hi Sue,
>
> Thanks for your positive comments. Let me add a few words to
> Philippe's answer.
>
> >Hi Rene,
> >I have tried out the Simple example now with the latest CVS version 3.01
> >of ROOT and find that it does work.  Very impressive!
> >We are hoping to use this new support of storing polymorphic objects
> >on a single ROOT TTree branch in our data model, and I have a new set
> >of questions related to how we can apply selection cuts to objects stored
> on
> >this type of branch.
> >Specifically, (using the Simple example to illustrate the types of cuts
> >I'd like to apply):
> >1) I would like to apply selection cuts to the SimpleTree fShape
> >branch by accessor method, e.g.:
> >"fShape -> GetVisibility() > 0"
> >In the past, I've found that I can use TTreeFormula to apply selection
> >cuts that include the use of accessor methods, but I find that with
> >the new TTree structure (TTree::SetBranchStyle(1);) that I cannot
> >successfully apply a cut using the above selection string.  (I attach
> >the write and read driver code that I'm using to test this.  The
> >Simple class is the same as that used in previous examples.) It does
> appear
> >that applying a selection cut without the use of accessor methods, e.g.:
> >"fID > 0" works successfully.
>
> As I told you in a previous mail, we are expecting to deliver the full
> functionality of the new branch mechanism for early June to be on time for
> the Root workshop at FNAL. It is now a question of a few weeks to get
> all the machinery in place. Queries like the one you mention are already
> operational in our private versions.
>  In the above query fShape is a TShape* but the real object may be any
> class derived from TShape. The query processor supports virtuality as in
> normal C++.
>
> >2) I would find it even better to be able to apply selection cuts to the
> >SimpleTree fShape branch using accessor methods from the derived
> >class of the object stored there.
> >For example, for an entry on the fShape branch containing a TTUBE,
> >I would like to be able to apply a selection cut of the form,
> >"fShape -> GetRmin() > 100"
> >I have been able to apply cuts such as this outside of TTreeFormula,
> >using the TMethodCall class, as in:
>
> This could be implemented, but I think it would be a bad idea to
> authorize this query as such. Because we want to be as close to the C++
> style as possible, we propose instead to use an explicit cast operation
> like "((TTUBE*)fShape)->GetRmin() > 100". In the query, we can eliminate
> easily and dynamically all shapes that are not TTUBE.
>
> >//...After retrieving simple object from TTree for a given entry
> >TShape* shape = simple -> GetShape();
> >TMethodCall *methodcall = new TMethodCall(shape->IsA(),"GetRmin","");
> >if (methodcall -> GetMethod()) {
> > // method "GetRmin" was found for this object
> > Double_t rmin;
> > methodcall -> Execute(shape,rmin);
> > if (rmin > 100) {
> >  // Entry passes cuts
> > }
> >}
> >delete methodcall;
>
> This is the technique used internally by the byte-code generated
> in the TTreeFormula internal compiler. However, I do not think that
> a user should invoke directly the TMethodCall class in a selection
> process. You better write your selection in plain C++ if you have
> to do things of this type.
>
> >but, I am wondering if the TTreeFormula class can also support this type
> >of dynamic use of accessor methods for the entries on the polymorphic
> >fShape branch.
>
> yes, it could, but, I think that an explicit cast is better.
>
> >3) I'd also find it desirable to be able to string accessor methods
> together,
> >e.g. apply a selection cut of the form:
> >"fShape -> GetMaterial() -> GetZ() > 8";
> >Is support for this something that can be added to the TTreeFormula
> class?
> >I notice that the set of TMethodCall::Execute methods includes those
> >which return basic data types, but not one which returns a pointer to
> >a TObject.  If there were such a version of TMethodCall::Execute, than it
> >seems like you could string the calls to the TMethodCall::Execute methods
> >together, e.g.
>
> The above query will be possible "fShape -> GetMaterial() -> GetZ() > 8".
> This can be implemented without having a TMethodCall::Execute returning
> a TObject*
>
> Rene Brun



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:43 MET