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