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