Hi Nick, I would like to see some progress in the discussion about TLorentzVector and TVector3. As you know, at the FNAL workshop in February, we decided to import the CLHEP implementation of these two classes to provide the same API between the two systems. We have received input from Pashat Murat and Martin Weber. Their requests make sense to me. As I am pretty convinced that not many people will access your files, could you make a summary of what you see missing in these two classes compared to your own implementation. Rene Brun Nick van Eijndhoven wrote: > > 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 > > ------------------------------------------------------------------------ > > Dr. Nick van Eijndhoven <nick@phys.uu.nl> > Utrecht University / Nikhef > Dept. of Subatomic Physics > > Dr. Nick van Eijndhoven > Utrecht University / Nikhef <nick@phys.uu.nl> > Dept. of Subatomic Physics > P.O. Box 80.000 Fax: +31-30-2518689 > NL-3508 TA Utrecht Work: +31-30-2532331 (secr. 2531492) > The Netherlands > At CERN : B160 1-012 Tel: +41-22-7679751 (secr. 7675857) Fax: +41-22-7679480 > Additional Information: > Last Name van Eijndhoven > First NameNick > Version 2.1
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:41 MET