Hi Pasha, For the ALICE reconstruction I already foresaw this and therefore I have made the classes Ali3Vector, Ali4Vector, AliTrack, AliJet, AliBoost etc... In these classes I have used a different approach than TLorentzVector to have exactly the functionality as you mention below. Note that in the Ali... classes I have also implemented support for introducing errors on all values and (automatic) error propgation. If you want you can have a look at the CERN /afs in ~nick/public/source/alice which contains all the source code and the corresponding docs are in the sub-directories of it. Note that some features of TLorentzVector are very attractive and not (yet) available in the Ali.... stuff. Therefore I am using both classes happily together in my analysis efforts. Cheers, Nick. "Pasha Murat (630)840-8237 FNAL (630)859-3463 home" wrote: > > Dear Rooters, > > I'd like to raise once again the issue of the relationship between > TLorentzVector and TVector3. I'm coming back to it every time I realize > that I can't do something as efficient and convenient as I'd like to. > > I've been clustering the tracks around the jets such that in the end > each jet would have tracks within the a certain eta-phi cone from jet > direction associated to it. By reconstruction a jet is a 4-vector - > calorimeter reconstructs its energy and angle, however for the same > reason a track is a 3-vector (you may not know its mass...). > > To associate a track and a jet one needs to calculate a distance > between them in eta-phi space > > dr(eta-phi) = sqrt((phi1-phi2)**2+(eta1-eta2)**2) > > where phi is an angle in XY and eta is a pseudorapidity of the track/jet. > The caveat is that while mathematically the operation itself is defined > for 2 3-vectors, what physicist has in hands is not 2 3-vectors, but a > 3-vector and a 4-vector. In case when 4-vector inherits from a 3-vector > one needs to provide a single function > > double TVector3::DrEtaPhi(TVector3*) > > which would do the job for all the possible cases. If however > TLorentzVector does not inherit from TVector3 (and this is what is > currently implemented in ROOT) to make life convenient one needs to > define at least 3 functions: > > (1) double TVector3::DrEtaPhi(TVector3*) > (2) double TLorentzVector::DrEtaPhi(TLorentzVector*) > (3) double TLorentzVector::DrEtaPhi(TVector3*) > > Also in this case one can't preserve symmetry between the arguments > because one can't have > > double TVector3::DrEtaPhi(TLorentzVector*) > > without 3-vectors "knowing" about 4-vectors... > > In the present implementation (2.23/07) of ROOT physics vectors the > 3rd function is missing, so the calculation of dr(eta-phi) becomes > a bit more cumbersome. Given > > TLorentzVector jet; > TVector3 track; > instead of > > double dr = jet.DrEtaphi(track); > > one needs to type > > double dr = jet.Vect().DrEtaPhi(track); > > The calculation also becomes less efficient because now it includes > creation/deletion of an intermediate 3-vector - jet.Vect(). > > In high energy physics there are quite a few operations which should be > symmetric with respect to 3-vectors and 4-vectors. I'd also argue that > when calculating any kind of angle between the 2 reconstructed objects > - tracks, muons, jets, photons etc, each of which could be either a > 3-vector or a 4-vector, - a physicist should not worry about the order > in which he types these 2 objects in in his code. I'd really like to be > able to type > > jet.DrEtaPhi(track) as well as track.DrEtaPhi(jet) > > without thinking about the C++-related issues at all. The language itself > allows to do this, for example via inheritance. There also could be other > possibilities and I'm wondering if this can be implemented? > > -Best, Pasha
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:41 MET