Hi,
Thanks for the replies. I have previously used TTree::MakeClass and it
works fine. Currently, I actually just write my own event loops to do this
which also works without any problems. I was just wondering, given the
recent extensions to TTree::Draw to handle arrays, how easy it would be to
add this extra functionality. I agree that conceptually, it may be slightly
non-intuative and a new syntax would have to be defined to parse the
command. ( fArray[i0] - fMatrix[i1][i2] for complete loops over fArray[] and
fMatrix[][]...? )
The reason the current implementation struck me as missing something was
that the looping over arrays was forced to match up indices where there
weren't necessarily suitable indices to match but a comparison still can be
made. Not a big point... partly just me being lazier than I should be. ;)
However, if the implementation is difficult then it's probably best left to
something along the lines of MakeClass and the user writing their own code.
Cheers, Dave
> I think that the existing mechanism provided by TTree::MakeClass
> is much more flexible and robust than the one based on coding in
> non-trivial (and sometimes non-intuitive) rules of interpreting
> the parameters passed to TTree::Draw().
> I woudn't say that TTree::MakeClass facility is perfect.
> For example, when a tree is written out in split mode, the
> autogenerated analysis function is very different from
> the function generated for the same tree written in non-split mode and
> very far from one might hope for. TTree::MakeClass doesn't
> always generate
> the code which compiles - see, for example, ROOTBUGS#708.
> However improving this utility seems to me to be the best direction
> for putting the efforts into.
>
> David - did you try to use the auto cogegen facility and if so,
> where didn't it work for you?
> -best, Pasha
>
> Philippe Canal wrote:
> >
> > Hi,
> >
> > This looks like a toughy, both conceptually and implementation wise.
> >
> > First, how should the Draw command decide what the user means by:
> >
> > t->Draw("hit.t","hit.id == hit_list.id");
> > or by
> > t->Draw("hit.t","hit.size == hit_ref.size");
> >
> > In which case should it do a lookup to find two different
> index that match (as David
> > is looking for) or do a simple index match (as it is now)?
> > I suppose, a new syntax could be invented to express these
> two differents semantics,
> > but it is really worth the extra complexity in syntax?
> >
> > In addition, codewise it would be a non-trivial change to
> add this concept.
> >
> > Philippe.
>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:29 MET