Hi Richard, Thanks for posting this very interesting mail including a pointer to your classes. We see now different implementations of the Physics vectors classes. I understand the arguments from you, Jeff and Nick. It would be good if more people could give their views on this topic. As I said yesterday, we started from the CLHEP class functionality thinking that after many years of design and test, these classes were mature and generally accepted by the community. My feeling is that these classes could/should may be improved based on your comments. I am getting several private mails from people reporting their frustation to see N+1 versions of these classes and their hope to see some convergence soon. Rene Brun Richard T. Jones wrote: > > Hello Rene, > > Back a few months ago, I looked at what was available in root and > CLHEP for doing 4-vector algebra and decided that what existed did not > look very extensible. At the time, I wanted to develop a OO > mini-framework for evaluating simple Feynman graphs. I think the > basic classes that I developed may be of general interest, beyond that > specific application. The main advantage of what I have over what > CLHEP had was: > > 1. identical interfaces for real and complex vectors > 2. unambiguous indexing methods > 3. coherence between 3-vectors and 4-vectors, for example 4-vectors > are derived from three-vectors, rotations and boosts are derived > from a common base class of LorentzTransform. > > I think that the classes have member functions for most of the common > operations with these types of objects, and each of them comes with > its own verifier that has fairly complete coverage. My implementation > does suffer from the criticism offered recently against internally > storing a 4-vector in four-component form, where rounding errors > affect the mass. This is most important for very small masses > compared to the energy scale, for example involving massive neutrinos, > something which did not occur to me at the time I designed the > classes. I have posted the docs for these classes using the automatic > root html generation method at URL. These objects do not currently > derive from TObject to keep them light-weight, but they have their own > streamers, overloaded shift, and Print() members and contain root > RTTI. > > http://zeus.phys.uconn.edu/refs/root/USER_Index.html > > The underlying classes are > > 1. TThreeVectorReal > 2. TThreeVectorComplex > 3. TFourVectorReal > 4. TFourVectorComplex > 5. TRotation > 6. TLorentzBoost > 7. TLorentzTransform > > with higher-level classes > > 1. TPauliSpinor > 2. TPauliMatrix > 3. TDiracSpinor > 4. TDiracMatrix > > I have also a class TCrossSection that calculates common QED cross > sections (Compton, bremsstrahlung) to leading order with full > polarization included. These classes allow one to write code that > resembles what one would write directly down on paper just looking at > a tree-level diagram, for example > > TDiracMatrix propagator1 = 1 / ( (TFourVectorReal *)p1->Slash() - > m) ); > > More complete examples are shown in TCrossSection. > > Richard Jones > University of Connecticut >
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:35 MET