CLHEP VERSION Reference Documentation
   
CLHEP Home Page     CLHEP Documentation     CLHEP Bug Reports

Typedefs | Functions | Variables
keyMergeIssues.doc File Reference

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< LorentzVectors
 
double m = s.invariantMass()
 
Application of Rotations and LorentzTransformations to containers of and as in Rotation R
 
std::vector< SpaceVectorvv
 
std::vector< SpaceVectorRvv = 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
 

Typedef Documentation

◆ v.r

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.

Function Documentation

◆ ABOUT()

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)

◆ axis()

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 ( )

◆ boostX()

HepLorentzVector& boostX ( double  beta)

◆ boostY()

HepLorentzVector& boostY ( double  beta)

◆ boostZ()

HepLorentzVector& boostZ ( double  beta)

◆ classes()

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)

◆ CLHEP()

most use the Hep3Vector implementations Since UnitVector is not in CLHEP ( for  now)

◆ colY()

HepRotation colY ( )

◆ colZ()

HepRotation colZ ( )

◆ delta()

HepRotation delta ( )

◆ et()

double et ( )

◆ et2()

double et2 ( )

◆ excpetions()

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. 
)

◆ exit()

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)

◆ Hep3Vector()

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)

◆ howNear()

HepRotation and so forth howNear ( )

◆ is() [1/2]

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().

◆ is() [2/2]

that avoids the design flaw of specialization by virtual non inheritance The entire implementation is ( by casting to Hep3Vector to get its  implementations)
inlinevirtual

◆ isLightlike()

bool isLightlike ( Scalar  epsilon = tolerance) const
inline

◆ isTimelike()

bool isTimelike ( ) const
inline

◆ 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 m2 ( )

◆ macros()

it has advantages For I leave the ZMthrows but substitute macros ( in ZMxpv.  h)

◆ 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 mag2 ( )

Referenced by main().

◆ 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()

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 
)

◆ operator>,operator<, operator>=, operator<=distance2()

HepRotation and so forth operator>, operator<, operator>=, operator<=distance2 ( )

◆ phi()

v phi ( )

◆ psi()

HepRotation psi ( )

Referenced by CLHEP::rotationOf(), and test().

◆ restMass2()

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 ( )

◆ Rotation()

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 
)

◆ rowX()

HepRotation rowX ( )

◆ rowY()

HepRotation rowY ( )

◆ rowZ()

HepRotation rowZ ( )

◆ setAxis()

HepRotation setAxis ( )

◆ setRhoPhiZ()

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  ,
 
)

◆ setRows()

HepRotation and so forth setRows ( )

◆ setRThetaPhi()

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 ( ,
theta  ,
phi   
)

◆ theta()

HepRotation theta ( )

◆ unit()

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 ( )

◆ When()

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)

Variable Documentation

◆ __pad0__

HepRotation __pad0__

Definition at line 140 of file keyMergeIssues.doc.

◆ 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 are

Definition at line 61 of file keyMergeIssues.doc.

◆ builds

this pulls in the ZOOM Exception behaviour Thus in our ZOOM builds

Definition at line 83 of file keyMergeIssues.doc.

◆ classes

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.

◆ CLHEP

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.

◆ cost

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.

◆ 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 defined

Definition at line 79 of file keyMergeIssues.doc.

◆ diff2

the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is diff2

Definition at line 410 of file keyMergeIssues.doc.

◆ discontinued

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.

◆ eta

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.

◆ example

the meanings are still clear from the comments For example

Definition at line 401 of file keyMergeIssues.doc.

◆ 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 features

Definition at line 77 of file keyMergeIssues.doc.

◆ 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 header

Definition at line 27 of file keyMergeIssues.doc.

◆ Hep4RotationInterface

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.

◆ 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 HepBoost

◆ 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 HepBoostX

Definition at line 304 of file keyMergeIssues.doc.

◆ in

it has advantages For I leave the ZMthrows in

◆ LTI

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.

◆ m

double m = s.invariantMass()

Definition at line 329 of file keyMergeIssues.doc.

◆ now

it has advantages For now

Definition at line 62 of file keyMergeIssues.doc.

Referenced by zmex::ZMexception::logMessage().

◆ 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 packages

Definition at line 7 of file keyMergeIssues.doc.

◆ 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 particular

Definition at line 28 of file keyMergeIssues.doc.

◆ R

Application of Rotations and LorentzTransformations to containers of and as in Rotation R

◆ repository

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.

◆ 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 RI

Definition at line 300 of file keyMergeIssues.doc.

◆ 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 RotationZ

Definition at line 294 of file keyMergeIssues.doc.

◆ Rvv

std::vector<SpaceVector> Rvv = R(vv)

Definition at line 335 of file keyMergeIssues.doc.

◆ s

Methods applicble to containers of as in std::list<LorentzVector> s

◆ 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 separate

Definition at line 26 of file keyMergeIssues.doc.

◆ small

the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is small

Definition at line 410 of file keyMergeIssues.doc.

Referenced by CLHEP::min_line_dist().

◆ 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 Some

Definition at line 270 of file keyMergeIssues.doc.

◆ 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 them

Definition at line 323 of file keyMergeIssues.doc.

◆ this

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.

◆ Thus

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.

◆ TimeNegative

Metric selector ZOOM allows the user to set metric as TimePositive or TimeNegative

Definition at line 408 of file keyMergeIssues.doc.

◆ trivial

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.

◆ use

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.

◆ used

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.

◆ usual

these appear together in RotationInterfaces h As usual

Definition at line 308 of file keyMergeIssues.doc.

◆ v

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 >().

◆ vectors

Application of Rotations and LorentzTransformations to containers of and vectors

Definition at line 327 of file keyMergeIssues.doc.

◆ vv

std::vector<SpaceVector> vv

◆ 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 workshop

Definition at line 15 of file keyMergeIssues.doc.

◆ ZMthrowA

it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package ZMthrowA

◆ ZOOM

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.