Re: Lorentz Vector Discussion

From: Pasha Murat (murat@cdfsga.fnal.gov)
Date: Tue Aug 17 1999 - 19:46:55 MEST


Physics Vectors give us a good example of that one might need a hierarchy 
of base classes. One could think about several levels of this hierarchy
(the one below are just a quick sketch):

- TObject0 : no data members, just a set of virtual functions
- TObject1 = today's TObjec -  adds Id and bit word
- TObject2 : adds graphics properties
- TNamed   = today's TNamed

Having such a hierarchy would resolve a bunch of issues related to physical
dependencies between different subpackages.

Then one can easily have small objects like 3-vectors, LorentzVectors etc 
inheriting from `TObject0' and from each other and being the data members of
each other w/o any memory overhead. I think we have a very good chance
to start a process of implementing such a hierarchy in evolutionary way, 
for example, by saying that today's `TObject' inherit from `TObject0' 
(so nothing would change above it) and that `TVector3' inherits from 
`TObject0' directly. 

Of course I'm making the assumption that normally one doesn't need to 
draw 3- or 4- vectors or to assign Id's to them - it is higher level objects 
which need to have these properties

Peter's proposal of TVector3Imp sounds like a very temporary kludge ...

back to Jeff Templton's proposal: it math operations have final 
precision and you lose accuracy when doing the calculations than it doesn't 
really matter what is stored in a 4-vector - mass or energy - you have a 
nonconservation of 3-momentum anyway ... Lorentz transformations can be 
implemented a bit more efficiently if 3-momentum and energy are stored.
When dealing with elementary particles we usually store one more particle 
attribute - PDG code - which always allows to retrieve the nominal value 
of particle's mass from the database, so mass conservation is not an issue.

						Best, Pasha
Peter Malzacher writes:
 > Hi
 > 
 > I have been in charge of upgrading the ROOT Physics Vectors by importing
 > the
 > existing CLHEP implementation.  The goal being to try to keep the number
 > of existing physics vector implementation as low as possible.  In the
 > process
 > we have been able to feed back some improvement back to the original
 > CLHEP.
 > A few of weeks ago, there has been a few reactions and proposal on this
 > upgrade.  I will try to answer to few of these as well as laying out our
 > plan for the next months.
 > 
 > 
 > 1) Interfaces.
 > 
 > The current interface is a combination of the interface in the original 
 > classes provided by Pasha Murat and the current version of CLHEP. As far 
 > as I see most of the functionality a Lorentz Vector class should provide
 > is
 > there.
 > 
 > Marc Fishler is working on the combination of the ZOOM and the CLHEP
 > Lorentz 
 > Vector packages. He should be finished by October. There is one concept
 > which 
 > will be added to the CLHEP classes: nearness between LorentzVectors. 
 > 
 > After he will have finished that work I will include that concept into
 > ROOTs
 > PHYSICS package, hopefully within 3 months.
 > 
 > 
 > 2) Underlying data (invariant mass vs. ernergy or time)
 > 
 > Jeff Templons proposal to take the invariant square of the LorentzVector
 > as fourth component (instead of energy or time) sounds ok. As far as I
 > see 
 > up to now, there are no drawbacks for physical acceptable LorentzVectors 
 > which outweight the advantage of not running into floating point
 > roundoff
 > errors. Therefore we should consider discussing this change to the CLHEP
 > maintainers. 
 > 
 > 
 > 3) Complex Vector
 > 
 > I do not see whether it is useful to include complex LorentzVectors etc.
 > along the line of Richard T. Jones.  I simply do not have the experience
 > to see whether a lot of ROOT users will benefit from such classes. I
 > think
 > a lot of the methods in the current set do not make to much sense for 
 > complexlorentz vectors.
 > 
 > 
 > 4) Implementation Detail
 > 
 > I also plan to tweak the implementation to make it as close as pratical
 > from
 > the CLHEP implementation while still not incurring unnecessary overhead. 
 > A lightweight TVector3Imp class which does not inherit from TObject will 
 > introduced and will be used as a member of the TLorentzVector class and 
 > parent of the TVector3 class without introducing overhead.
 > The structure of the classes will then be the same as in CLHEP. 
 > The current interface of TVector3 and TLorentzVector will not change, 
 > beside the addition of new fuctions (see above 1. )
 > 
 > Peter Malzacher



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:38 MET