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

Matrix/CLHEP/Utility/keywords.h
Go to the documentation of this file.
1 #ifndef CLHEP_KEYWORDS_H
2 #define CLHEP_KEYWORDS_H
3 
4 // ======================================================================
5 //
6 // keywords - allow use of C++0X keywords
7 //
8 // Author: W. E. Brown; 2010-03-19
9 //
10 // ======================================================================
11 
12 
13 #include "CLHEP/Utility/defs.h"
14 
15 
16 // C++0X-like keywords: remove once C++0X is here to stay
17 //#define constexpr const
18 //#define noexcept throw()
19 //#define nullptr 0
20 
21 
22 #endif // CLHEP_KEYWORDS_H
23 //
24 // ======================================================================
colZ
HepRotation colZ()
delta
HepRotation delta() setPhi()
vv
std::vector< SpaceVector > vv
Definition: keyMergeIssues.doc:334
tests
Test tests[]
Definition: testBug90848.cc:27
place
At least for we will omit so as not to introduce template complications into CLHEP If we can put this back in the LorentzVector h file in the ZOOM area that typedefs LorentzVector from HepLorentzVector And if there is a tremendous desire for this from the CLHEP we can provide this capability be suppying a header file which users can optionally include(Since these are templated global methods, all information can naturally go into a header file which need not be included if these methods are not called.) 26 - Unit 4-Vectors along each axis This takes advantage of ISOcxx which handles all the of places where things like sqrt are found CLHEP has its own congfigure for and till ISOcxx is in place
Definition: minorMergeIssues.doc:221
colY
HepRotation colY()
properties
How the various random distributions are validated The distributions in for example are independently validated By we mean checking that *The algorithm is mathematically correct *The algorithm is properly coded *The compilation of the algorithm is proper for this plaform *There is no subtle interaction between the algorithm and the random engine used that detectably impacts the distribution This validation must be done without reference to the coded algorithm and testing that these obey the mathematical properties of the desired distribution For each those we reject if the distribution is sigma away from the proper properties
Definition: validation.doc:23
three
@ three
Definition: testCategories.cc:136
interface
there is no the time needed for times is not significantly certainly not enough to warrant the additional complication So we simple provide the transform method taking a rotation interface
Definition: merge-details.doc:55
example
user code seldom needs to call this function directly ZMerrno whether or not they are still recorded ZMerrno whether or not they are still since the user counter was last ZMerrno while ZMerrno ZMerrno while ZMerrno to note the handler and logger used when the exception was ZMthrow n etc The resulting pointer should generally be checked against in case ZMerrno does not go back as far as requested ZMerrno for example
Definition: mechanics_ZMx.txt:382
pollution
ZOOM classes Symbol pollution
Definition: merge-details.doc:7
l
long l
Definition: JamesRandomSeeding.txt:30
setting
ZOOM classes Symbol which is defined in the SpaceVector h backward compatibility header This has the consequence that ThreeVector h is considerably since the plethora of constructors is greatly reduced Spherical coordinate setting
Definition: merge-details.doc:14
exceptions
Ouch may be arbitrary text to be associated with this particular as described below Resulting log message Assuming that the ExcTest program has been compiled with appropriate compiler switches that enable use of exceptions
Definition: mechanics_ZMx.txt:90
m
double m
Definition: keyMergeIssues.doc:329
LorentzVector
In alll angles are always treated as measured in RADIANS Spherical coordinate setting mof V in LorentzVector
Definition: merge-details.doc:22
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, z) operator/
way
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return but since these methods or signatures don t appear in the original ZOOM this can t break any so I leave the void return type alone for those After discussion with A P and I have modified the return types of other CLHEP methods which return void and would by the same reasoning be better returning *this These include rotate and boost methods in LorentzVector h HepLorentzVector explicit and leads to division by zero if this vector has which takes very little time I think the zoom implementation is therefore better by the way
Definition: minorMergeIssues.doc:141
ZMthrow
#define ZMthrow(userExcept)
Definition: CLHEP/Exceptions/ZMthrow.h:97
isTimelike
bool isTimelike() const
cc
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom cc
Definition: JamesRandomSeeding.txt:8
boostX
HepLorentzVector & boostX(double beta)
usual
these appear together in RotationInterfaces h As usual
Definition: keyMergeIssues.doc:308
a
@ a
Definition: testCategories.cc:125
used
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package when used
Definition: keyMergeIssues.doc:69
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.) Hep3Vector(similarly HepLorentzVector etc.) is not enclosed in a namespace. In ZOOM
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
Definition: keyMergeIssues.doc:304
CLHEP::condition
double condition(const HepSymMatrix &m)
Definition: MatrixLinear.cc:198
setRows
HepRotation and so forth setRows() compare()
only
the naive Gaussian approximation is inaccurate at a level for turns out to be detectable in a sample of only
Definition: validation.doc:330
do
When exceptions are the ZMthrow macro looks we know the try part will throw why not just do
Definition: whyZMthrowRethrows.txt:23
b
@ b
Definition: testCategories.cc:125
zmpv
Definition: Geometry/CLHEP/Vector/AxisAngle.h:106
than
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default which makes use of the table of and the seed is the xor of a mask which starts with a bit and the seed from the table But it and often supply a seed of more than
Definition: JamesRandomSeeding.txt:18
LT
@ LT
Definition: Evaluator.cc:67
thus
thus
Definition: mechanics_ZMx.txt:328
boostZ
HepLorentzVector & boostZ(double beta)
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: keyMergeIssues.doc:323
is
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
SpaceVector
In alll angles are always treated as measured in RADIANS The full set of original signatures for set are still implemented via the SpaceVector h header for compatibility with ZOOM use Use of UnitVector Some code at Fermilab uses and I have also found some situations where the efficiency can make a significant difference I provide UnitVector as a class for ZOOM users in the zmpv namespace via a file UnitVector h This no longer inherits from SpaceVector
Definition: minorMergeIssues.doc:30
here
the goal is to keep the overall false rejection probability down at the to level For each validated we discuss here
Definition: validation.doc:35
methods
ZOOM classes Symbol which is defined in the SpaceVector h backward compatibility header This has the consequence that ThreeVector h is considerably since the plethora of constructors is greatly reduced Spherical coordinate the user can still use the we provide a few new methods
Definition: merge-details.doc:16
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: keyMergeIssues.doc:77
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()
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: keyMergeIssues.doc:307
et2
double et2()
instead
we want to make it possible for the user to use the so instead
Definition: minorMergeIssues.doc:19
takes
Signatures of Hep3Vector::rotate For equivalent ZOOM takes(axis, delta) where CLHEP takes(delta
rotate
Signatures of Hep3Vector::rotate For equivalent rotate() methods
CLHEP::TimePositive
@ TimePositive
Definition: Geometry/CLHEP/Vector/LorentzVector.h:65
phi
v phi()
Definition: minorMergeIssues.doc:20
howNear
HepRotation and so forth howNear()
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() and delta()
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: keyMergeIssues.doc:80
one
@ one
Definition: testCategories.cc:136
mechanism
At least for we will omit so as not to introduce template complications into CLHEP If we can put this back in the LorentzVector h file in the ZOOM area that typedefs LorentzVector from HepLorentzVector And if there is a tremendous desire for this from the CLHEP we can provide this capability be suppying a header file which users can optionally include(Since these are templated global methods, all information can naturally go into a header file which need not be included if these methods are not called.) 26 - Unit 4-Vectors along each axis This takes advantage of ISOcxx which handles all the of places where things like sqrt are found CLHEP has its own congfigure mechanism
Definition: minorMergeIssues.doc:220
vectors
Methods applicble to containers of vectors
Definition: keyMergeIssues.doc:327
code
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return but since these methods or signatures don t appear in the original ZOOM this can t break any code
Definition: minorMergeIssues.doc:115
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: keyMergeIssues.doc:411
size
user code seldom needs to call this function directly ZMerrno whether or not they are still recorded ZMerrno size() Return the(integer) number of ZMthrow 'n exceptions currently recorded. 5) ZMerrno.clear() Set an internal counter to zero. This counter is available(see next function) to user code to track ZMthrow 'n exceptions that have occurred during any arbitrary time interval. 6) ZMerrno.countSinceCleared() Return the(integer) number of ZMthrow 'n exceptions that have been recorded via ZMerrno.write()
less
there is no the time needed for times is not significantly less
Definition: merge-details.doc:53
diff2
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is diff2
Definition: keyMergeIssues.doc:410
any
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its a code describing if any
Definition: ZMthrow_event_sequence.txt:148
not
if not
Definition: ZMthrow_event_sequence.txt:51
get
user code seldom needs to call this function directly ZMerrno whether or not they are still recorded ZMerrno whether or not they are still since the user counter was last ZMerrno while ZMerrno ZMerrno get() gives a(const pointer to) the latest recorded exception
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: keyMergeIssues.doc:300
n_element_type::test
void test()
Definition: testSharedPtr.cc:41
Z
Definition: testSharedPtrConvertible.cc:34
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: keyMergeIssues.doc:26
these
In these
Definition: merge-details.doc:18
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: keyMergeIssues.doc:152
Method
the goal is to keep the overall false rejection probability down at the to level For each validated we discuss which of course is by necessity relative timing We take the time for a single random via one of the fastest good and at any rate the ratios will vary by around depending on the processor and memory configuration used A timing for a distribution of units would mean no time used beyond the uniform random Summary Distribution Validated Validation Rejected Past N RandGauss RandGaussT RandGaussQ bins stepwise bins RandPoisson RandPoissonT mu< 100 N=50, 000, 000 ------- mu > RandPoissonQ mu< 100 N=50, 000, 000 -------(same as RandPoissonT) mu > RandGauss Method
Definition: validation.doc:63
psi
HepRotation psi() axis()
CLHEP
Definition: ClhepVersion.h:13
small
the default is TimePositive CLHEP always does TimePositive The cost of the flexibility is small
Definition: keyMergeIssues.doc:410
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: keyMergeIssues.doc:271
zmpv::AxisAngle
CLHEP::HepAxisAngle AxisAngle
Definition: Geometry/CLHEP/Vector/AxisAngle.h:108
above
In the example above
Definition: mechanics_ZMx.txt:49
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: keyMergeIssues.doc:324
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(r, theta, phi) setREtaPhi(r
structure
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 structure
Definition: merge-details.doc:116
macros
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
theta
HepRotation theta()
rowY
HepRotation rowY()
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) the actual ZOOM exceptions package is incorporated into Vector ZMthrowC may eventually be handle the selective continuiing. However
result
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its result
Definition: ZMthrow_event_sequence.txt:148
TimeNegative
Metric selector ZOOM allows the user to set metric as TimePositive or TimeNegative
Definition: keyMergeIssues.doc:408
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: keyMergeIssues.doc:62
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: keyMergeIssues.doc:124
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) 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
however
In alll angles are always treated as measured in RADIANS Spherical coordinate setting mof V in however
Definition: merge-details.doc:22
UnitVector
In alll angles are always treated as measured in RADIANS The full set of original signatures for set are still implemented via the SpaceVector h header for compatibility with ZOOM use Use of UnitVector Some code at Fermilab uses UnitVector
Definition: minorMergeIssues.doc:28
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: keyMergeIssues.doc:270
Exception
Definition: exctest2.cc:8
package
Introduction to the Use of Zoom Exceptions W E last revised Jan Introduction This summary describes the mechanics decided on for creating and throwing a ZMexception as implemented by the zoom Exceptions package Note that all public C symbols used within this Exceptions class begin with the unlikely prefix we use ZMexception as the name of the class from which all other exception classes all ZOOM generated ZMexception classes will use at least ZMx as their name prefix More to avoid internal name the names start with a short string identifying the package
Definition: mechanics_ZMx.txt:21
Genfun::dot
std::complex< double > dot(const SphericalHarmonicCoefficientSet &, const SphericalHarmonicCoefficientSet &)
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() and mag()
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: keyMergeIssues.doc:7
clashes
Introduction to the Use of Zoom Exceptions W E last revised Jan Introduction This summary describes the mechanics decided on for creating and throwing a ZMexception as implemented by the zoom Exceptions package Note that all public C symbols used within this Exceptions class begin with the unlikely prefix we use ZMexception as the name of the class from which all other exception classes all ZOOM generated ZMexception classes will use at least ZMx as their name prefix More to avoid internal name clashes
Definition: mechanics_ZMx.txt:21
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: keyMergeIssues.doc:79
ZMthrowC
#define ZMthrowC(A)
Definition: Geometry/CLHEP/Vector/ZMxpv.h:132
algorithm
I could not create a faster method completely accurate that does not require overly large tables and takes a major step up when we cross for several values of but we have applied this with much higher N We validated the main trials It showed no sign of approaching the rejectable p values or errors in mean and sigma the method matches the original algorithm
Definition: validation.doc:308
Rvv
std::vector< SpaceVector > Rvv
Definition: keyMergeIssues.doc:335
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: keyMergeIssues.doc:28
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()
output
std::ofstream output("ranRestoreTest.cout")
does
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default which makes use of the table of and the seed is the xor of a mask which starts with a bit and the seed from the table But it and often does
Definition: JamesRandomSeeding.txt:18
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: keyMergeIssues.doc:304
what
this formatted text is the function s string result this method sends the formatted string s to the ostream destination specified when the logger was instantiated as its a code describing what
Definition: ZMthrow_event_sequence.txt:148
j
long j
Definition: JamesRandomSeeding.txt:28
seeds
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default which makes use of the table of seeds(with some trickery to ensure that the values won 't repeat after the table rows are exhausted). The trickery preserves the fact that sees are never negative(because the table values are never negative
HepGeom::Vector3D< double >
Definition: CLHEP/Geometry/Vector3D.h:102
set
set(pkginclude_HEADERS itos.h) INSTALL(FILES $
Definition: Cast/Cast/CMakeLists.txt:2
like
When exceptions are the ZMthrow macro looks like
Definition: whyZMthrowRethrows.txt:13
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 LTI
Definition: keyMergeIssues.doc:303
example
the meanings are still clear from the comments For example
Definition: keyMergeIssues.doc:401
s
Methods applicble to containers of as in std::list< LorentzVector > s
Definition: keyMergeIssues.doc:328
ctor
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default ctor
Definition: JamesRandomSeeding.txt:12
boostY
HepLorentzVector & boostY(double beta)
Note
The given behavior will apply to any exceptions ZMthrow n after the handler has been established Available handlers Here is a list of the five standard handlers that are defined via the Exceptions package Each is accompanied by a brief description of its after become the object of a C throw but will have no further affect on subsequent control flow after be thrown if its severity is ZMexERROR or but be ignored if of a lesser severity Note
Definition: mechanics_ZMx.txt:218
i
long i
Definition: JamesRandomSeeding.txt:27
rowZ
HepRotation rowZ() phi()
This
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained and costs nothing I don t wish to potentially break ZOOM user code for no good so I have made these CLHEP method conform to this convention There are a couple of other CLHEP rotate and which use the void return but since these methods or signatures don t appear in the original ZOOM this can t break any so I leave the void return type alone for those After discussion with A P and I have modified the return types of other CLHEP methods which return void and would by the same reasoning be better returning *this These include rotate and boost methods in LorentzVector h HepLorentzVector explicit and leads to division by zero if this vector has which takes very little time I think the zoom implementation is therefore better This
Definition: minorMergeIssues.doc:141
behavior
The given behavior will apply to any exceptions ZMthrow n after the handler has been established Available handlers Here is a list of the five standard handlers that are defined via the Exceptions package Each is accompanied by a brief description of its behavior
Definition: mechanics_ZMx.txt:188
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(). ZOOM does not have a method m2(). So we leave m2 as metric independant
HepGeom::Rotate3D
Definition: CLHEP/Geometry/Transform3D.h:375
for
for(n=1 ;n< 98 ;n++)
Definition: JamesRandomSeeding.txt:34
dependency
#define dependency
isLightlike
bool isLightlike(Scalar epsilon=tolerance) const
now
it has advantages For now
Definition: keyMergeIssues.doc:62
R
Application of Rotations and LorentzTransformations to containers of and as in Rotation R
Definition: keyMergeIssues.doc:333
can
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default which makes use of the table of and the seed is the xor of a mask which starts with a bit and the seed from the table But it can
Definition: JamesRandomSeeding.txt:17
after
logging can probably cease after(say) 50 of the same warnings. ZMexERROR We encountered something such that
reject
How the various random distributions are validated The distributions in for example are independently validated By we mean checking that *The algorithm is mathematically correct *The algorithm is properly coded *The compilation of the algorithm is proper for this plaform *There is no subtle interaction between the algorithm and the random engine used that detectably impacts the distribution This validation must be done without reference to the coded algorithm and testing that these obey the mathematical properties of the desired distribution For each those we reject if the distribution is sigma away from the proper we reject
Definition: validation.doc:23
in
it has advantages For I leave the ZMthrows in
Definition: keyMergeIssues.doc:62
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 classes
Definition: keyMergeIssues.doc:29
hand
any side effects of that construction would occur twice The semantics of throw on the other hand
Definition: whyZMthrowRethrows.txt:37
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: keyMergeIssues.doc:27
which
the naive Gaussian approximation is inaccurate at a level which
Definition: validation.doc:329
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). Also
et
double et()
rowX
HepRotation rowX()
ZMthrowA
it has advantages For I leave the ZMthrows but substitute I replaced ZMthrow with ZMthrowA in this package ZMthrowA
Definition: keyMergeIssues.doc:69
k
long k
Definition: JamesRandomSeeding.txt:29
else
MATCHES Darwin else() set(Vector_source_list $
Definition: Vector/src/CMakeLists.txt:40
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: keyMergeIssues.doc:320
take
often useful for progress reporting and for debugging purposes ZMexWARNING Something unusual has but we have a quite reasonable action to take
Definition: mechanics_ZMx.txt:137
name
user code seldom needs to call this function directly ZMerrno whether or not they are still recorded ZMerrno whether or not they are still since the user counter was last ZMerrno name() gives the(string) name of the latest recorded exception
angle
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and angle(in itself quite a task) then douing vector *
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: keyMergeIssues.doc:294
operations
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity then rotating that by axis and I leave the CLHEP code alone people are of course free to use the ZOOM originated method with signature which I believe will be faster Return types for rotateZ CLHEP and PhysicsVectors each have these three and they are identical except that the ZOOM version returns a reference to while in CLHEP they return void Having methods that alter an object return a reference to that object is convenient for certain chained operations
Definition: minorMergeIssues.doc:109
with
this we validated with
Definition: validation.doc:308
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: keyMergeIssues.doc:61
zmpv::EulerAngles
CLHEP::HepEulerAngles EulerAngles
Definition: Geometry/CLHEP/Vector/EulerAngles.h:106
However
We have the boost methods returning HepLorentzVector &rather than so things can be chained we feel the boost methods along an boostZ in really ought to be in the main part of the header ZOOM does several checks to see that the boost vector is not tachyonic However
Definition: minorMergeIssues.doc:158
process
Technical Maintenance Note for CLHEP Random Consequences of seeding JamesRandom with positive seed values greater than In the source code JamesRandom The usual way of seeding a generator is via the default which makes use of the table of and the seed is the xor of a mask which starts with a bit and the seed from the table But it and often supply a seed of more Does that adversely affect the behavior of the engine We look at the seeding process
Definition: JamesRandomSeeding.txt:18
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: keyMergeIssues.doc:275
setAxis
HepRotation setAxis()
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) generic Rotations and LorentzTransformations. For example
problem
ought always be logged ZMexFATAL We can make no representations as to the state of any part of the even of software parts not obviously associated with the failed intended action and even if you try to handle the problem
Definition: mechanics_ZMx.txt:156
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: keyMergeIssues.doc:309
Also
We have the boost methods returning HepLorentzVector &rather than so things can be chained Also
Definition: minorMergeIssues.doc:155