CLHEP VERSION Reference Documentation
CLHEP Home Page CLHEP Documentation CLHEP Bug Reports |
Typedefs | |
using | v.r = 4.), and have been applied and pass. This deomnstrates that no ZOOM functionallity other than the few identified cutbacks has been compromised. Also, since the ZOOM classes other than UnitVector directly utilize the CHEP classes(mostly by typedef), the very extensive ZOOM test suite heavily excercises 90% of the methods of all the CLHEP classes. The exceptions are such methods as v.orthogonal() and R.rotateAxes(vx, vy, vz) which were not in the original ZOOM package. Since the ZOOM area is not being checked back into the original CLHEP, these extensive tests are not going to be part of CLHEP. If somebody feels it worthwhile to place these tests into CLHEP/Vector/tests and change the names of the classes to the Hep names, this would be reasonable, but I will not give any priority for myself to do it.================================================================================================================================================... And a few less major issues:------------------------------------------- Coupling between Hep3Vector and HepRotation ------------------------------------------- In PhysicsVectors, there was a heirarchy in which vectors do not know about rotations. The methods Hep3Vector::transform(const HepRotation &) and Hep3Vector *=(const HepRotation &) break this heirarchy. Thus in the opriginal CLHEP, **any clhep program that used Hep3Vector would link in hepRotation.cc. This is not desirable. As part of the merge, I broke apart ThreeVector.cc, putting the HepRotation dependent methods in their own little file, ThreeVectorR.cc. If the user uses Hep3Vectors but not HepRotations, he won 't pull everything in. Similarly for HepLorentzVector, with regards to uses HepRotation and HepLorentzRotation. ----------------------------- R, rho nomenclature confusion ----------------------------- In ThreeVector, CLHEP, --IN COMMENTS ONLY-- refers to the radius in spherical coordinates as "rho", and the distance from the Z axis in cylindrical coordinates as R. ZOOM uses the oppopsite names, and in fact uses these names in method names. I did not change the ZOOM method names. I have altered the CLHEP comments to make the nomenclature consistent |
Functions | |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a | Hep3Vector (for example) means. We are not forming SpaceVector as an class derived from Hep3Vector and enhancing it in that way. Another rule imposed by the agreement is to avoid using the Exceptions package(even though that will later go into CLHEP for other uses). A desirable goal is to avoid cluttering the interface and enlarging the code linked in when ordinary CLHEP Vector functionallity is used. To this end |
it has advantages For I leave the ZMthrows but substitute | macros (in ZMxpv.h) which turn usage of ZXMthrow into cerr<< message lines.(Issuing of messages to cerr is done elsewhere in Vectors.) To avoid clashes with other ZOOM packages in the definition of the ZMthrow macro |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and | exit (-1). Also |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem | When (if ever) the actual ZOOM exceptions package is incorporated into Vector ZMthrowC may eventually be handle the selective continuiing. However |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to(an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions(and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist | setRThetaPhi (r, theta, phi) setREtaPhi(r |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to(an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions(and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist phi | setRhoPhiZ (rho, phi, z) operator/ |
bool | isTimelike () const |
bool | isLightlike (Scalar epsilon=tolerance) const |
HepLorentzVector & | boostX (double beta) |
HepLorentzVector & | boostY (double beta) |
HepLorentzVector & | boostZ (double beta) |
double | et () |
double | et2 () |
HepRotation | colY () |
HepRotation | colZ () |
HepRotation | rowX () |
HepRotation | rowY () |
HepRotation | rowZ () phi() |
HepRotation | theta () |
HepRotation | psi () axis() |
HepRotation | delta () setPhi() |
HepRotation | setAxis () |
HepRotation and so forth | setRows () compare() |
HepRotation and so forth | operator>,operator<, operator>=, operator<=distance2 () |
HepRotation and so forth | howNear () |
HepRotation and so forth isNear() norm2() rectify() static Rotation row1 row4(To avoid bloat in the code pulled in for programs which don 't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM we will set up so as to use ZOOM | excpetions (The version placed into the official CLHEP, however, will not use ZOOM Exceptions at this point.) Hep3Vector(similarly HepLorentzVector etc.) is not enclosed in a namespace. In ZOOM |
HepRotation and so forth isNear() norm2() rectify() static Rotation row1 row4(To avoid bloat in the code pulled in for programs which don 't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM we will set up so as to use ZOOM SpaceVector | is (but we can disable namespace usage and most of our users do so at this point). What I do is leave Hep3Vector in the global namespace |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation | is (by casting to Hep3Vector to get its implementations) so no additional code need go into the CLHEP library. Since UnitVector is not in CLHEP |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP | classes (in particular not Hep3Vector and not HepRotation) will be aware of the existance of UnitVector. Note that although UnitVector does not inherit from Hep3Vector |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector like | unit () and mag() |
most use the Hep3Vector implementations Since UnitVector is not in | CLHEP (for now) we just retain the name UnitVector. However |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion | operator to Hep3Vector makes it trivial to use UnitVector as an argument to any routine that takes a Hep3Vector. There will be cases where it would be beneficial to have a special method taking advantage of the knowledge that a UnitVector need not be normalized. For the present, we will not attempt to obtain this advantage. --------------------------------------- Rotation classes inheritance structure:--------------------------------------- I am telescoping a lot of thought into a few words here. ZOOM has RotationInterface and LorentzTransformationInterface (for short, RI and LTI) |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION | ABOUT (but not modifying) generic Rotations and LorentzTransformations. For example |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods | axis () and delta() |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from | Rotation (that would introduce a bunch of inapplicable methods, plus greatly increase the size of member data for RotationX). Similarly |
v | phi () |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this | mag2 () |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this | m2 () |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this and restMass2() for LorentzVector what we call in ZOOM | restMass2 (). ZOOM does not have a method m2(). So we leave m2 as metric independant |
Variables | |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a | RotationZ |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From | RI |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from | LTI |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with | HepBoost |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with | HepBoostX |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI &and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with and so forth The Hep classes expressing RI and LTI are Hep3RotationInterface and | Hep4RotationInterface |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these | packages |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP | workshop |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a | separate |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the | header |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In | particular |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP | classes |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes | are |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes I am not giving up on it eventually being in | use |
it has advantages For | now |
it has advantages For I leave the ZMthrows | in |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package | ZMthrowA |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when | used |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception | features |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception we provide in ZMxpv h a define of ENABLE_ZOOM_EXCEPTIONS In CLEHP this is not | defined |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception we provide in ZMxpv h a define of ENABLE_ZOOM_EXCEPTIONS In CLEHP this is not and ZMthrowA and ZMthrowC become macros that behave as above When we build for | ZOOM |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM | builds |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to(an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions(and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist | eta |
HepRotation | __pad0__ |
HepRotation and so forth isNear() norm2() rectify() static Rotation row1 row4(To avoid bloat in the code pulled in for programs which don 't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM | repository |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector | Some |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector like become quite | trivial |
most use the Hep3Vector implementations Since UnitVector is not in it may eventually become part of | CLHEP |
most use the Hep3Vector implementations Since UnitVector is not in it may eventually become part of so I chose to parallel the situation for SpaceVector w r t Hep3Vector | Thus |
these appear together in RotationInterfaces h As | usual |
namespace guarded::In ZOOM we had in the inheritance tree classes RotationAboutCoordinateAxis and BoostAlongCoordinateAxis These mainly let us avoid duplication of code but were not useful enought to be worth their complexity | cost |
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been | discontinued |
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been after checking that no existing user code was utilizing | them |
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been after checking that no existing user code was utilizing as in SpaceVector | v |
Methods applicble to containers of | vectors |
Methods applicble to containers of as in std::list< LorentzVector > | s |
double | m = s.invariantMass() |
Application of Rotations and LorentzTransformations to containers of and as in Rotation | R |
std::vector< SpaceVector > | vv |
std::vector< SpaceVector > | Rvv = R(vv) |
the meanings are still clear from the comments For | example |
Metric selector ZOOM allows the user to set metric as TimePositive or | TimeNegative |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is | small |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is | diff2 |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of | this |
using v.r = 4.), and have been applied and pass. This deomnstrates that no ZOOM functionallity other than the few identified cutbacks has been compromised. Also, since the ZOOM classes other than UnitVector directly utilize the CHEP classes (mostly by typedef), the very extensive ZOOM test suite heavily excercises 90% of the methods of all the CLHEP classes. The exceptions are such methods as v.orthogonal() and R.rotateAxes(vx,vy,vz) which were not in the original ZOOM package. Since the ZOOM area is not being checked back into the original CLHEP, these extensive tests are not going to be part of CLHEP. If somebody feels it worthwhile to place these tests into CLHEP/Vector/tests and change the names of the classes to the Hep names, this would be reasonable, but I will not give any priority for myself to do it. ======================================================================== ======================================================================== ... And a few less major issues: ------------------------------------------- Coupling between Hep3Vector and HepRotation ------------------------------------------- In PhysicsVectors, there was a heirarchy in which vectors do not know about rotations. The methods Hep3Vector::transform(const HepRotation &) and Hep3Vector*=(const HepRotation &) break this heirarchy. Thus in the opriginal CLHEP, **any clhep program that used Hep3Vector would link in hepRotation.cc. This is not desirable. As part of the merge, I broke apart ThreeVector.cc, putting the HepRotation dependent methods in their own little file, ThreeVectorR.cc. If the user uses Hep3Vectors but not HepRotations, he won't pull everything in. Similarly for HepLorentzVector, with regards to uses HepRotation and HepLorentzRotation. ----------------------------- R, rho nomenclature confusion ----------------------------- In ThreeVector, CLHEP, --IN COMMENTS ONLY-- refers to the radius in spherical coordinates as "rho", and the distance from the Z axis in cylindrical coordinates as R. ZOOM uses the oppopsite names, and in fact uses these names in method names. I did not change the ZOOM method names. I have altered the CLHEP comments to make the nomenclature consistent |
Definition at line 399 of file keyMergeIssues.doc.
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION ABOUT | ( | but not | modifying | ) |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods axis | ( | ) |
HepLorentzVector& boostX | ( | double | beta | ) |
HepLorentzVector& boostY | ( | double | beta | ) |
HepLorentzVector& boostZ | ( | double | beta | ) |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP classes | ( | in particular not Hep3Vector and not | HepRotation | ) |
most use the Hep3Vector implementations Since UnitVector is not in CLHEP | ( | for | now | ) |
HepRotation colY | ( | ) |
HepRotation colZ | ( | ) |
HepRotation delta | ( | ) |
Referenced by CLHEP::RandSkewNormal::gaussianSkewNormal(), CLHEP::HepLorentzVector::howNear(), CLHEP::HepLorentzVector::isNear(), Genfun::PuncturedSmearedExp::operator()(), CLHEP::operator>>(), poissonTest(), CLHEP::HepLorentzRotation::rotateX(), CLHEP::HepLorentzRotation::rotateY(), CLHEP::HepLorentzRotation::rotateZ(), skewNormalTest(), and CLHEP::ZMinputAxisAngle().
double et | ( | ) |
double et2 | ( | ) |
HepRotation and so forth isNear () norm2() rectify() static Rotation row1 row4 (To avoid bloat in the code pulled in for programs which don't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM we will set up so as to use ZOOM excpetions | ( | The version placed into the official | CLHEP, |
however | , | ||
will not use ZOOM Exceptions at this | point. | ||
) |
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a Hep3Vector | ( | for | example | ) |
Referenced by CLHEP::HepRotation::axis(), CLHEP::HepLorentzVector::boostVector(), conversion_test(), CLHEP::HepLorentzVector::findBoostToCM(), CLHEP::HepRotation::getAngleAxis(), main(), HepGeom::BasicVector3D< float >::operator CLHEP::Hep3Vector(), HepGeom::Normal3D< double >::operator CLHEP::Hep3Vector(), HepGeom::Vector3D< double >::operator CLHEP::Hep3Vector(), HepGeom::Point3D< double >::operator CLHEP::Hep3Vector(), CLHEP::Hep2Vector::operator Hep3Vector(), and CLHEP::operator/().
HepRotation and so forth howNear | ( | ) |
HepRotation and so forth isNear () norm2() rectify() static Rotation row1 row4 (To avoid bloat in the code pulled in for programs which don't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM we will set up so as to use ZOOM SpaceVector is | ( | but we can disable namespace usage and most of our users do so at this | point | ) |
Referenced by anonymousRestore2(), anonymousRestoreStatics(), checkEngineInstanceSave(), checkRandGeneralDistribution(), checkSaveDistribution(), checkSharingDistributions(), CLHEP::DRand48Engine::DRand48Engine(), CLHEP::DualRand::DualRand(), CLHEP::RandPoissonQ::get(), CLHEP::RandPoissonT::get(), CLHEP::RandPoisson::get(), CLHEP::RandStudentT::get(), CLHEP::RandLandau::get(), CLHEP::NonRandomEngine::get(), CLHEP::MTwistEngine::get(), CLHEP::RandBit::get(), CLHEP::Hurd288Engine::get(), CLHEP::Hurd160Engine::get(), CLHEP::RandGaussZiggurat::get(), CLHEP::HepJamesRandom::get(), CLHEP::RandSkewNormal::get(), CLHEP::Ranlux64Engine::get(), CLHEP::RandExponential::get(), CLHEP::TripleRand::get(), CLHEP::RanshiEngine::get(), CLHEP::HepRandom::get(), CLHEP::DualRand::get(), CLHEP::RandChiSquare::get(), CLHEP::RanecuEngine::get(), CLHEP::DRand48Engine::get(), CLHEP::RandEngine::get(), CLHEP::RandBinomial::get(), CLHEP::RandGamma::get(), CLHEP::HepRandomEngine::get(), CLHEP::RanluxEngine::get(), CLHEP::RandGaussQ::get(), CLHEP::RandExpZiggurat::get(), CLHEP::RandGauss::get(), CLHEP::RandGaussT::get(), CLHEP::RandGeneral::get(), CLHEP::RandBreitWigner::get(), CLHEP::RandFlat::get(), CLHEP::NonRandomEngine::getState(), CLHEP::MTwistEngine::getState(), CLHEP::Hurd288Engine::getState(), CLHEP::Hurd160Engine::getState(), CLHEP::HepJamesRandom::getState(), CLHEP::Ranlux64Engine::getState(), CLHEP::TripleRand::getState(), CLHEP::RanshiEngine::getState(), CLHEP::DualRand::getState(), CLHEP::RanecuEngine::getState(), CLHEP::RandEngine::getState(), CLHEP::DRand48Engine::getState(), CLHEP::RanluxEngine::getState(), CLHEP::HepRandomEngine::getState(), CLHEP::HepJamesRandom::HepJamesRandom(), CLHEP::Hurd160Engine::Hurd160Engine(), CLHEP::Hurd288Engine::Hurd288Engine(), CLHEP::HepSymMatrix::invertBunchKaufman(), CLHEP::MTwistEngine::MTwistEngine(), CLHEP::EngineFactory::newEngine(), CLHEP::HepRandomEngine::newEngine(), CLHEP::operator>>(), HepGeom::operator>>(), CLHEP::possibleKeywordInput(), CLHEP::RandEngine::RandEngine(), CLHEP::RanecuEngine::RanecuEngine(), CLHEP::Ranlux64Engine::Ranlux64Engine(), CLHEP::RanluxEngine::RanluxEngine(), CLHEP::RanshiEngine::RanshiEngine(), CLHEP::StaticRandomStates::restore(), CLHEP::RandBit::restoreDistState(), CLHEP::HepRandom::restoreDistState(), CLHEP::RandGauss::restoreDistState(), CLHEP::RandFlat::restoreDistState(), CLHEP::RandBit::restoreFullState(), CLHEP::HepRandom::restoreFullState(), CLHEP::RandGauss::restoreFullState(), CLHEP::RandFlat::restoreFullState(), CLHEP::HepRandom::restoreStaticRandomStates(), restoreStatics(), CLHEP::TripleRand::TripleRand(), CLHEP::ZMinput2doubles(), CLHEP::ZMinput3doubles(), and CLHEP::ZMinputAxisAngle().
|
inlinevirtual |
|
inline |
|
inline |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this m2 | ( | ) |
Referenced by compareR(), and Genfun::ClebschGordanCoefficientSet::operator()().
it has advantages For I leave the ZMthrows but substitute macros | ( | in ZMxpv. | h | ) |
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this mag2 | ( | ) |
Referenced by main().
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion operator to Hep3Vector makes it trivial to use UnitVector as an argument to any routine that takes a Hep3Vector. There will be cases where it would be beneficial to have a special method taking advantage of the knowledge that a UnitVector need not be normalized. For the present, we will not attempt to obtain this advantage. --------------------------------------- Rotation classes inheritance structure:--------------------------------------- I am telescoping a lot of thought into a few words here. ZOOM has RotationInterface and LorentzTransformationInterface | ( | for short | , |
RI and | LTI | ||
) |
HepRotation and so forth operator>, operator<, operator>=, operator<=distance2 | ( | ) |
v phi | ( | ) |
Definition at line 20 of file minorMergeIssues.doc.
Referenced by main(), CLHEP::rotationOf(), CLHEP::rotationXOf(), CLHEP::rotationYOf(), CLHEP::rotationZOf(), HepGeom::BasicVector3D< float >::setEta(), and test().
HepRotation psi | ( | ) |
Referenced by CLHEP::rotationOf(), and test().
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of I am keeping metric flexibility in the package Pure CLHEP users need never see this and restMass2 () for LorentzVector what we call in ZOOM restMass2 | ( | ) |
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI& and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from Rotation | ( | that would introduce a bunch of inapplicable | methods, |
plus greatly increase the size of member data for | RotationX | ||
) |
HepRotation rowX | ( | ) |
HepRotation rowY | ( | ) |
HepRotation rowZ | ( | ) |
HepRotation setAxis | ( | ) |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to (an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions (and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist phi setRhoPhiZ | ( | rho | , |
phi | , | ||
z | |||
) |
HepRotation and so forth setRows | ( | ) |
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to (an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions (and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist setRThetaPhi | ( | r | , |
theta | , | ||
phi | |||
) |
HepRotation theta | ( | ) |
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector like unit | ( | ) |
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem When | ( | if | ever | ) |
HepRotation __pad0__ |
Definition at line 140 of file keyMergeIssues.doc.
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes are |
Definition at line 61 of file keyMergeIssues.doc.
Definition at line 83 of file keyMergeIssues.doc.
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP classes |
Definition at line 29 of file keyMergeIssues.doc.
most use the Hep3Vector implementations Since UnitVector is not in it may eventually become part of CLHEP |
Definition at line 274 of file keyMergeIssues.doc.
namespace guarded:: In ZOOM we had in the inheritance tree classes RotationAboutCoordinateAxis and BoostAlongCoordinateAxis These mainly let us avoid duplication of code but were not useful enought to be worth their complexity cost |
Definition at line 309 of file keyMergeIssues.doc.
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception we provide in ZMxpv h a define of ENABLE_ZOOM_EXCEPTIONS In CLEHP this is not defined |
Definition at line 79 of file keyMergeIssues.doc.
Definition at line 410 of file keyMergeIssues.doc.
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been discontinued |
Definition at line 320 of file keyMergeIssues.doc.
this pulls in the ZOOM Exception behaviour Thus in our ZOOM people still get the ZOOM Exceptions behaviour they are used to (an absolute requirement for us) -- but pure CLHEP users do not see the Exceptions package at all. The only slight annoyance is that now for ZOOM users CLHEP will depend on Exceptions (and ZMutility) -- where a minimalist would note that only the CLHEP/Vector subpackage needed to depend on these even in ZOOM. The linker is such a minimalist eta |
Definition at line 124 of file keyMergeIssues.doc.
the meanings are still clear from the comments For example |
Definition at line 401 of file keyMergeIssues.doc.
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception features |
Definition at line 77 of file keyMergeIssues.doc.
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the header |
Definition at line 27 of file keyMergeIssues.doc.
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI& and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with and so forth The Hep classes expressing RI and LTI are Hep3RotationInterface and Hep4RotationInterface |
Definition at line 307 of file keyMergeIssues.doc.
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI& and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with HepBoost |
Definition at line 304 of file keyMergeIssues.doc.
Referenced by CLHEP::HepBoostX::decompose(), CLHEP::HepBoostZ::decompose(), CLHEP::HepBoostY::decompose(), and CLHEP::HepLorentzRotation::rectify().
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI& and take because anything you wish to ask about a LT you could equally well ask about a Rotation From one derives Rotation and its special cases RotationX etc We can t derive RotationX from from one derives HepLorentzRotation along with HepBoostX |
Definition at line 304 of file keyMergeIssues.doc.
it has advantages For I leave the ZMthrows in |
Definition at line 62 of file keyMergeIssues.doc.
Referenced by CLHEP::RandGauss::restoreEngineStatus(), CLHEP::RandFlat::restoreEngineStatus(), CLHEP::MTwistEngine::restoreStatus(), CLHEP::Hurd288Engine::restoreStatus(), CLHEP::Hurd160Engine::restoreStatus(), CLHEP::HepJamesRandom::restoreStatus(), CLHEP::Ranlux64Engine::restoreStatus(), CLHEP::RanshiEngine::restoreStatus(), CLHEP::TripleRand::restoreStatus(), CLHEP::RandEngine::restoreStatus(), CLHEP::RanecuEngine::restoreStatus(), CLHEP::DualRand::restoreStatus(), CLHEP::DRand48Engine::restoreStatus(), and CLHEP::RanluxEngine::restoreStatus().
Z these are I think new Just check against the equivalent form by instantiating a general Lor Rot based on a ROtationX and so forth Rotation LorentzBoostZ These are useful and will become part of CLHEP THe boost classes may be in their own header file Inheritance which provide those methods available for GETTING INFORMATION ABOUT generic Rotations and LorentzTransformations We should keep these The proper inheritance is that RI derives from because anything you wish to ask about a LT you could equally well ask about a R From LTI |
Definition at line 303 of file keyMergeIssues.doc.
double m = s.invariantMass() |
Definition at line 329 of file keyMergeIssues.doc.
it has advantages For now |
Definition at line 62 of file keyMergeIssues.doc.
Referenced by zmex::ZMexception::logMessage().
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these packages |
Definition at line 7 of file keyMergeIssues.doc.
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In particular |
Definition at line 28 of file keyMergeIssues.doc.
Definition at line 333 of file keyMergeIssues.doc.
Referenced by CLHEP::back_solve(), CLHEP::HepLorentzRotation::decompose(), main(), CLHEP::HepLorentzRotation::rectify(), and CLHEP::HepLorentzRotation::set().
HepRotation and so forth isNear () norm2() rectify() static Rotation row1 row4 (To avoid bloat in the code pulled in for programs which don't use all these features, we split the implementation .cc files. Only isNear() goes into the original Rotation.cc) --------------------------------------- HepAxisAngle and HepEulerAngles classes --------------------------------------- These classes are very useful and simple structures for holding the result of a nice intuituve decomposition of a rotation there is no longer much content in the distinct ZOOM PhysicsVectors library The only content left in the library is the object files representing the various Exception objects When we build the CLHEP classes for the ZOOM repository |
Definition at line 152 of file keyMergeIssues.doc.
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a since RI has methods a routine can be passed a RI& and take because anything you wish to ask about a LT you could equally well ask about a Rotation From RI |
Definition at line 300 of file keyMergeIssues.doc.
namespace and inside the zmpv namespace it typedef s UnitVector to be HepUnit3Vector The conversion which provide those methods available for GETTING INFORMATION if an object might be either a Rotation or a RotationZ |
Definition at line 294 of file keyMergeIssues.doc.
std::vector<SpaceVector> Rvv = R(vv) |
Definition at line 335 of file keyMergeIssues.doc.
Methods applicble to containers of as in std::list<LorentzVector> s |
Definition at line 328 of file keyMergeIssues.doc.
Referenced by CLHEP::crc32ul(), main(), CLHEP::NonRandomEngine::setRandomSequence(), CLHEP::HepJamesRandom::setSeed(), n_report_2::foo::setWeak(), and n_report_2::test().
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a separate |
Definition at line 26 of file keyMergeIssues.doc.
Definition at line 410 of file keyMergeIssues.doc.
Referenced by CLHEP::min_line_dist().
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector Some |
Definition at line 270 of file keyMergeIssues.doc.
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been after checking that no existing user code was utilizing them |
Definition at line 323 of file keyMergeIssues.doc.
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is and mag2 and no other routines are altered Because of this |
Definition at line 411 of file keyMergeIssues.doc.
most use the Hep3Vector implementations Since UnitVector is not in it may eventually become part of so I chose to parallel the situation for SpaceVector w r t Hep3Vector Thus |
Definition at line 275 of file keyMergeIssues.doc.
Definition at line 408 of file keyMergeIssues.doc.
that avoids the design flaw of specialization by virtual non inheritance The entire implementation of necessity no CLHEP const EVERY method of Hep3Vector is present for UnitVector like become quite trivial |
Definition at line 271 of file keyMergeIssues.doc.
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP the approach is to combine the features of each ZOOM class with the corresponding CLHEP class expanding the interface to create a single lingua franca of what a I have placed almost all the new features in a second section of the and have created separate cc files for sensible subsets of the methods In if a program uses only the methods found in the original CLHEP very little additional code is linked in Classes The corresponding classes I am not giving up on it eventually being in use |
Definition at line 62 of file keyMergeIssues.doc.
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when used |
Definition at line 69 of file keyMergeIssues.doc.
Definition at line 308 of file keyMergeIssues.doc.
they are gone ZOOM Features Discontinued The following features of the ZOOM package were felt to be extreme overkill These have been after checking that no existing user code was utilizing as in SpaceVector v |
Definition at line 324 of file keyMergeIssues.doc.
Referenced by HepGeom::BasicVector3D< float >::angle(), anonymousRestore(), anonymousRestore1(), anonymousRestore1< NonRandomEngine >(), anonymousRestore2(), aSequence(), HepGeom::BasicVector3D< float >::BasicVector3D(), CLHEP::col_house(), CLHEP::Hep2Vector::compare(), CLHEP::Hep3Vector::compare(), HepGeom::BasicVector3D< float >::cross(), CLHEP::Hep3Vector::deltaR(), Genfun::AbsFunction::derivative(), HepGeom::BasicVector3D< float >::dot(), CLHEP::DoubConv::dto2longs(), Classical::RungeKuttaSolver::equationOf(), eval(), MyEvaluator::evaluate(), CLHEP::RandStudentT::fire(), CLHEP::RandSkewNormal::fireArray(), CLHEP::RandExponential::fireArray(), CLHEP::RandChiSquare::fireArray(), CLHEP::RandBinomial::fireArray(), CLHEP::RandPoisson::fireArray(), CLHEP::RandGamma::fireArray(), CLHEP::RandGaussQ::fireArray(), CLHEP::RandGauss::fireArray(), CLHEP::RandLandau::fireArray(), CLHEP::RandStudentT::fireArray(), CLHEP::RandPoissonQ::fireArray(), CLHEP::RandGaussT::fireArray(), CLHEP::RandBreitWigner::fireArray(), CLHEP::NonRandomEngine::flat(), CLHEP::NonRandomEngine::get(), CLHEP::MTwistEngine::get(), CLHEP::Hurd288Engine::get(), CLHEP::Hurd160Engine::get(), CLHEP::HepJamesRandom::get(), CLHEP::Ranlux64Engine::get(), CLHEP::TripleRand::get(), CLHEP::RanshiEngine::get(), CLHEP::DualRand::get(), CLHEP::RanecuEngine::get(), CLHEP::RandEngine::get(), CLHEP::DRand48Engine::get(), CLHEP::RanluxEngine::get(), CLHEP::NonRandomEngine::getState(), CLHEP::Hurd288Engine::getState(), CLHEP::MTwistEngine::getState(), CLHEP::Hurd160Engine::getState(), CLHEP::HepJamesRandom::getState(), CLHEP::Ranlux64Engine::getState(), CLHEP::TripleRand::getState(), CLHEP::RanshiEngine::getState(), CLHEP::DualRand::getState(), CLHEP::RanecuEngine::getState(), CLHEP::RandEngine::getState(), CLHEP::DRand48Engine::getState(), CLHEP::RanluxEngine::getState(), CLHEP::house(), CLHEP::house_with_update(), CLHEP::house_with_update2(), CLHEP::Hep3Vector::howNear(), CLHEP::Hep2Vector::howOrthogonal(), CLHEP::Hep3Vector::howOrthogonal(), CLHEP::Hep2Vector::howParallel(), CLHEP::Hep3Vector::howParallel(), CLHEP::Hep3Vector::isNear(), CLHEP::Hep2Vector::isOrthogonal(), CLHEP::Hep3Vector::isOrthogonal(), CLHEP::Hep2Vector::isParallel(), CLHEP::Hep3Vector::isParallel(), CLHEP::DoubConv::longs2double(), main(), CLHEP::EngineFactory::newEngine(), CLHEP::HepRandomEngine::newEngine(), Genfun::LogisticFunction::operator()(), Genfun::FunctionComposition::operator()(), HepGeom::BasicVector3D< float >::operator*(), HepGeom::BasicVector3D< float >::operator+(), HepGeom::BasicVector3D< float >::operator+=(), HepGeom::BasicVector3D< float >::operator-(), HepGeom::BasicVector3D< float >::operator-=(), HepGeom::BasicVector3D< float >::operator/(), CLHEP::Hep2Vector::operator<(), CLHEP::Hep3Vector::operator<(), CLHEP::operator<<(), CLHEP::Hep2Vector::operator<=(), CLHEP::Hep3Vector::operator<=(), HepGeom::Normal3D< float >::operator=(), HepGeom::Point3D< float >::operator=(), HepGeom::Vector3D< float >::operator=(), CLHEP::HepVector::operator=(), HepGeom::BasicVector3D< float >::operator=(), HepGeom::Vector3D< double >::operator=(), HepGeom::Normal3D< double >::operator=(), HepGeom::Point3D< double >::operator=(), CLHEP::Hep2Vector::operator>(), CLHEP::Hep3Vector::operator>(), CLHEP::Hep2Vector::operator>=(), CLHEP::Hep3Vector::operator>=(), CLHEP::operator>>(), HepGeom::BasicVector3D< float >::perp(), HepGeom::BasicVector3D< float >::perp2(), CLHEP::NonRandomEngine::put(), CLHEP::Hurd288Engine::put(), CLHEP::Hurd160Engine::put(), CLHEP::MTwistEngine::put(), CLHEP::HepJamesRandom::put(), CLHEP::Ranlux64Engine::put(), CLHEP::TripleRand::put(), CLHEP::RanshiEngine::put(), CLHEP::DualRand::put(), CLHEP::RanecuEngine::put(), CLHEP::DRand48Engine::put(), CLHEP::RanluxEngine::put(), CLHEP::RandEngine::put(), CLHEP::HepRandomEngine::put(), CLHEP::Hurd288Engine::restoreStatus(), CLHEP::Hurd160Engine::restoreStatus(), CLHEP::HepJamesRandom::restoreStatus(), CLHEP::Ranlux64Engine::restoreStatus(), CLHEP::TripleRand::restoreStatus(), CLHEP::RanshiEngine::restoreStatus(), CLHEP::RanecuEngine::restoreStatus(), CLHEP::RandEngine::restoreStatus(), CLHEP::DualRand::restoreStatus(), CLHEP::DRand48Engine::restoreStatus(), CLHEP::RanluxEngine::restoreStatus(), HepGeom::BasicVector3D< float >::rotate(), CLHEP::row_house(), CLHEP::Hurd288Engine::saveStatus(), CLHEP::Hurd160Engine::saveStatus(), CLHEP::HepJamesRandom::saveStatus(), CLHEP::Ranlux64Engine::saveStatus(), CLHEP::RandEngine::saveStatus(), CLHEP::RanshiEngine::saveStatus(), CLHEP::TripleRand::saveStatus(), CLHEP::RanecuEngine::saveStatus(), CLHEP::DualRand::saveStatus(), CLHEP::RanluxEngine::saveStatus(), CLHEP::DRand48Engine::saveStatus(), myRotClass::setXX(), myRotClass::setXY(), myRotClass::setXZ(), myRotClass::setYX(), myRotClass::setYY(), myRotClass::setYZ(), myRotClass::setZX(), myRotClass::setZY(), myRotClass::setZZ(), CLHEP::RandStudentT::shoot(), CLHEP::RandSkewNormal::shootArray(), CLHEP::RandExponential::shootArray(), CLHEP::RandChiSquare::shootArray(), CLHEP::RandBinomial::shootArray(), CLHEP::RandGamma::shootArray(), CLHEP::RandGaussQ::shootArray(), CLHEP::RandBreitWigner::shootArray(), CLHEP::RandGauss::shootArray(), CLHEP::RandPoisson::shootArray(), CLHEP::RandStudentT::shootArray(), CLHEP::RandGaussT::shootArray(), CLHEP::RandLandau::shootArray(), CLHEP::RandPoissonQ::shootArray(), Classical::PhaseSpace::start(), Classical::PhaseSpace::startValue(), CLHEP::RandEngineBuilder< int >::thirtyTwoRandomBits(), CLHEP::RandGaussQ::transformSmall(), CLHEP::transformSmall(), useSeed(), vectorRestore(), vectorRestore1(), vectorRestore1< NonRandomEngine >(), vectorRestore2(), vectorTest64(), and vectorTest64< NonRandomEngine >().
Application of Rotations and LorentzTransformations to containers of and vectors |
Definition at line 327 of file keyMergeIssues.doc.
std::vector<SpaceVector> vv |
Definition at line 334 of file keyMergeIssues.doc.
Referenced by CLHEP::rotationOf(), CLHEP::rotationXOf(), CLHEP::rotationYOf(), and CLHEP::rotationZOf().
Issues Concerning the PhysicsVectors CLHEP Vector Merge The merge of ZOOM PhysicsVdectors and the CLHEP Vector package is completed The purpose of this document is to list the major issues that affected the merge of these and where relevant describe the resolutions More detailed documents describe more minor issues General Approach As agreed at the June CLHEP workshop |
Definition at line 15 of file keyMergeIssues.doc.
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package ZMthrowA |
Definition at line 69 of file keyMergeIssues.doc.
Referenced by CLHEP::Hep3Vector::beta(), CLHEP::HepLorentzVector::beta(), CLHEP::HepLorentzVector::boost(), CLHEP::HepLorentzVector::boostVector(), CLHEP::HepLorentzVector::boostX(), CLHEP::HepLorentzRotation::boostX(), CLHEP::HepLorentzVector::boostY(), CLHEP::HepLorentzRotation::boostY(), CLHEP::HepLorentzVector::boostZ(), CLHEP::HepLorentzRotation::boostZ(), CLHEP::Hep3Vector::coLinearRapidity(), CLHEP::HepLorentzVector::coLinearRapidity(), CLHEP::Hep3Vector::eta(), CLHEP::HepLorentzVector::findBoostToCM(), CLHEP::Hep3Vector::gamma(), CLHEP::HepLorentzVector::gamma(), CLHEP::HepLorentzVector::invariantMass(), CLHEP::HepLorentzVector::minus(), CLHEP::Hep2Vector::operator()(), CLHEP::operator/(), CLHEP::Hep3Vector::operator/=(), CLHEP::HepLorentzVector::operator/=(), CLHEP::HepLorentzVector::plus(), CLHEP::Hep3Vector::project(), CLHEP::HepLorentzVector::rapidity(), CLHEP::Hep3Vector::rapidity(), CLHEP::HepLorentzRotation::rectify(), CLHEP::HepRotation::rectify(), CLHEP::Hep3Vector::rotate(), CLHEP::HepBoostZ::set(), CLHEP::HepBoostY::set(), CLHEP::HepBoostX::set(), CLHEP::HepBoost::set(), CLHEP::HepLorentzRotation::set(), CLHEP::Hep3Vector::setMag(), and CLHEP::Hep3Vector::setRhoPhiTheta().
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when will issue its message and I introduce a macro ZMthrowC which I use wherever it seems there is a sensible way to continue processing after reporting the problem we don t want to change the functionallity when this is used in the ZOOM context To retain true ZOOM Exception we provide in ZMxpv h a define of ENABLE_ZOOM_EXCEPTIONS In CLEHP this is not and ZMthrowA and ZMthrowC become macros that behave as above When we build for ZOOM |
Definition at line 80 of file keyMergeIssues.doc.