// Vector Doxygen doc page
/**
\page Vector Generic Vector for 3 and 4 Dimensions
This is a proposal for a new vector package, @b GenVector,
describing vectors and their operations in 2, 3, and 4 dimensions.
The 4 dimensional space is used for describing relativistic particles.
These vectors are different from generic vectors of the Linear Algebra package which describe N-dimensional vectors. The functionality of this package is currently provided by the CLHEP Vector And
Geometry packages and the %ROOT Physics Vector classes (Tvector2, TVector3 and TLorentzVector). It is also re-uses concepts and ideas from the CMS Common Vector package.
The main characteristics of this package are :
Minimal interface
We define a minimal interface trying to avoid duplications in contrast to what is currently provided by the Vector package of CLHEP.
- We try to avoid methods providing the same functionality but with different names ( like getX() and x() in CLHEP).
- we minimize the number of setter methods, avoiding methods which can set the Vector classes in an inconsistent state.
We provide only methods which set all the coordinates at the same time and we enforce the use of transformations as rotations or translations (additions) for modifying the vector contents.
- The majority of the functionality, which is present in the CLHEP package, involving operations on two vectors, is moved in separated helper functions (see ROOT::Math::VectorUtil). This has the advantage that the basic interface will remain more stable with time while additional functions can be added easily.
We adopted a compromised between a simple interface and user convenience. We could have gone to the extreme of having a class containing only the scalar data, with member functions only returning the data themself and move all the other functionality in separate functions. This approach, although it has some appeal, it requires a complete change from the way these classes are used. We have therefore prefer to keep a more conservative approach, mantaining the most used functions inside the vector classes, and moving other fuctionality outside as global functions in a namespace.
In addition, our choice of having all the coordinate accessors inside the vector classes, provides us the possibility of specializing the vector classes depending on the coordinate system.
Optimal runtime performances
We try to minimize any overhead in the run-time performances. We have deliberatly avoided to have any virtual function and even virtual destructors in the classes and have inlined as much as possible all the functions.
Generic scalar type
For maximum flexibility and minimize in some use case memory allocation, the vector classes are templated on the scalar type. To avoid exposing templated parameter to the users, typedefs are defined for
vectors based on float and double's.
Coordinate Type
The Vector (and point classes) are based on a generic type of coordinates. Various classes exist to describe the different coordinates, such as Cartesian (for 3, and 4 dimensions), Polar for dimension 3 and Cylindrical for 3 and 4 dimensions.
Users can define the Vectors according to the coordinate type which is most efficient for their use. For performances reason, we prefer to implement this concept using template classes instead of inheritance.
Points and Vector concept
Mathematically Vectors and Points are two distinct concepts. They have different transformations, like Vectors only rotate while Points rotate and translate. You can add two vectors but not two points and the difference between two points is a vector. In contrast to the CLHEP Vector package, but as in the CLHEP Geometry package and in the CMS Vector package,
we distinguish for the 3 dimensions, between Points and Vectors. They are defined as two distinct types; Points are described by the
ROOT::Math::PositionVector3D class while Vectors by the
ROOT::Math::DisplacementVector3D class.
Therefore only some transformations are allowed, for example it is not allowed to add two points, and translations have no effect on Vectors. Comparing to the CMS Vector package, we don't want to distinguish between Vectors according to their reference frame, for example between local frame vector and global frame vectors.
We have recognized a limited needs for this functionality and a too high cost for including this additional complexity.
Transformations
We describe also some geometrical 3D transformations such as rotations and translations and Lorentz 4D transformations which are composed by a boost and a 3D rotation.
Example of Usage
- \ref Vector3DPage
- \ref Point3DPage
- \ref LorentzVectorPage
- \ref TransformPage
- ROOT::Math::VectorUtil (Helper functions)
- \ref ExtUsagePage
Packaging
This classes will be part of the basic Math library, libMathCore.
All of the classes and functions will be in the namespace,
ROOT::Math.
Current Status and Time Scale
This current version is avaliable with the ROOT development version 5.04.
A tar file of all MathCore is downloadable from
here.
Backward compatibility with %ROOT and CLHEP Vector classes
When these classes will be available in ROOT, we will create adapter (proxy) classes replacing the current %ROOT Vector classes (TVector3, TLorentzVector, TRotation and TLorentzRotation). For example a new TLorentzVector, will still inherit from TObject and contain an instance to the new ROOT::Math::LorentzVector class. All the TLorentzVector member functions will be implemented forwarding the calls to the ROOT::Math::LorentzVector. Since all these methods will be inlined, the performance overhead expected for TLorentzVector will be negligible.
For mantaining some compatibility with CLHEP and easy the migration, we have decided to keep the same naming convention as CLHEP for the interfaces for some of the most used functions.
For example we will have a ROOT::Math::XYZVector::x(), y() and z() as in CLHEP.
References
- CLHEP Vector package (User guide and reference doc)
- CLHEP Geometry package
- %ROOT Physics Vector classes
- CMS Vector package
@authors The %ROOT Math Library Team
@b Contact:
*/