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