Hi Nick, Hi Jeff,
As both of you know, we have introduced in 2.22 new versions of the
classes
TVector3 and TLorentzVector. We had several iterations with the FNAL
team
supporting ZOOM & CLHEP. We finally agreed on an implementation that
you can find in 2.22/09 released yesterday.
Since both of you do not specify which version of Root you are referring
to,
I am not sure that you are talking of the same thing.
During the discussions with FNAL, we investigated the point if
TLorentzVector
should derive from TVector3 or not. There are pros/cons with the two
approaches.
The idea was to converge with the CLHEP versions of LorentzVector.
We are convinced that for frequently used classes such as
TLorentzVector,
it is not a good idea that everybody implements his own version.
We had many comments from users that a convergence should be possible
and it is a very frustating situation to see different implementations.
The current implementation in 2.22/09 does not derive from TVector3, but
all the functionality from TVector3 is available in TLorentzVector.
I would like to understand what are precisely the criticisms with the
current implementation.
Jeff, please give more details on the problems.
Nick, indicate the strong points of your version (possibly weak
points)
compared to TlorentzVector.
This class is fully documented at URL:
http://root.cern.ch/root/html/TLorentzVector.html
I hope to have some input from FNAL ZOOM/CLHEP teams on this point.
Rene Brun
Nick van Eijndhoven wrote:
>
> Jeff Templon wrote:
> >
> > Hi,
> >
> > I saw Pasha's message of a few days ago about the new LorentzVector
> > class and thought I'd weigh in with a couple of concerns.
> >
> > First, I am surprised about the lack of "interknowledge" of a
> > LorentzVector with its three-vector as well. I am prototyping a
> > Monte-Carlo program for electron scattering just to evaluate ROOT/C++
> > as a platform for a further, bigger project. I have four-vector
> > classes I wrote (in Python) before, and the ones in ROOT operate
> > totally differently.
> >
> > The tack I took was that the invariant square of the vector was
> > _invariant_ so that this, not the fourth component (energy or time)
> > was the fourth data member. This has the advantage that if one
> > changes the momentum of a vector (through a process such as ionization
> > energy loss), you can simply reset the momentum and let the class
> > figure out the energy by itself that is necessary to keep the mass
> > identical. It sees to me that with the current ROOT classes, lots of
> > extra work is necessary if you worry about keeping the invariant
> > square really invariant under operations on a four-vector.
> >
> > Given the design decision made by the ROOT team, there should be other
> > convenience functions. Perhaps this is what is meant by the function
> >
> > void SetVectM(TVector3& spatial, Double_t mass)
> >
> > but it was not too obvious from the documentation. And again not
> > preserving the invariant mass under operations has led to
> > floating-point roundoff difficulties for me in the past; in my first
> > version of four-vector classes I took the same approach as the ROOT
> > classes did.
> >
> > JAT
>
> Hi Jeff,
> I indeed followed a similar track for Ali4Vector & co. for the ALICE reco.
> software. Therefore having TLorentzVector & co. coexisting with Ali4Vector & co.
> in our AliRoot framework gives us the full functionality and benefits of the
> both approaches.
> Furthermore, as I mentioned earlier, I stumbled over some more rounding problems
> when I tried the stuff out on high energy neutrino events (a la AMANDA) where
> one needs boosts from one frame to the other. Also here having both 'packages'
> available enabled me overcoming all problems.
> --
>
> Cheers,
> Nick.
>
> *----------------------------------------------------------------------*
> Dr. Nick van Eijndhoven Department of Subatomic Physics
> email : nick@phys.uu.nl Utrecht University / NIKHEF
> tel. +31-30-2532331 (direct) P.O. Box 80.000
> tel. +31-30-2531492 (secr.) NL-3508 TA Utrecht
> fax. +31-30-2518689 The Netherlands
> WWW : http://www.phys.uu.nl/~nick Office : Ornstein lab. 172
> ----------------------------------------------------------------------
> tel. +41-22-7679751 (direct) CERN PPE Division / ALICE exp.
> tel. +41-22-7675857 (secr.) CH-1211 Geneva 23
> fax. +41-22-7679480 Switzerland
> CERN beep : 13+7294 Office : B 160 1-012
> *----------------------------------------------------------------------*
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:35 MET