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

Mod.cc
Go to the documentation of this file.
1 // -*- C++ -*-
2 // $Id:
4 #include <cmath>
5 #include <limits.h>
6 namespace Genfun {
8 
9 Mod::Mod(double y):
10  _y(y)
11 {}
12 
13 Mod::Mod(const Mod & right)
14  : AbsFunction(right), _y(right._y)
15 {}
16 
18 }
19 
20 
21 // HAD BEEN:
22 // double Mod::operator() (double x) const {
23 // return drem_local(x-_y/2.0,_y) + _y/2.0;
24 //}
25 
26 double Mod::operator() (double x) const {
27  return (x - _y*floor(x/_y));
28 }
29 
30 } // namespace Genfun
delta
HepRotation delta() setPhi()
m
double m
Definition: minorMergeIssues.doc:165
LorentzBoostX
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 LorentzBoostX
Definition: merge-details.doc:111
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
main
int main()
Definition: testBug66214.cc:30
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
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 * this
Definition: minorMergeIssues.doc:105
crowd
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 crowd
Definition: minorMergeIssues.doc:171
set
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 set() methods in spherical coordinates. Except that again the keywords DERGREES RADIANS ETA are not available. Instead
pollution
ZOOM classes Symbol pollution
Definition: merge-details.doc:7
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
double
#define double(obj)
Definition: excDblThrow.cc:32
LorentzVector
In alll angles are always treated as measured in RADIANS Spherical coordinate setting mof V in LorentzVector
Definition: merge-details.doc:22
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
usual
these appear together in RotationInterfaces h As usual
Definition: keyMergeIssues.doc:308
a
@ a
Definition: testCategories.cc:125
RI
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 one derives and each of the boosts From RI
Definition: merge-details.doc:121
ignore
always safe to ignore
Definition: mechanics_ZMx.txt:125
Genfun::AbsFunction
Definition: CLHEP/GenericFunctions/AbsFunction.hh:48
methods
we want to make it possible for the user to use the so we provide a few new methods
Definition: minorMergeIssues.doc:19
LorentzBoost
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 LorentzBoost
Definition: merge-details.doc:110
CLHEP::HepYHat
const Hep3Vector HepYHat
Definition: Geometry/CLHEP/Vector/ThreeVector.h:425
rotateY
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 rotateY
Definition: minorMergeIssues.doc:102
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
rotateX
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 rotateX
Definition: minorMergeIssues.doc:102
do
When exceptions are the ZMthrow macro looks we know the try part will throw why not just do
Definition: whyZMthrowRethrows.txt:23
now
At least for now
Definition: minorMergeIssues.doc:167
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
example
we want to make it possible for the user to use the so we provide a few new for example
Definition: minorMergeIssues.doc:20
set
we want to make it possible for the user to use the set() methods in spherical coordinates. But(see item 4.1) the keywords DERGREES RADIANS ETA are not available in Hep3Vector
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
classes
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 classes
Definition: minorMergeIssues.doc:115
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
HepGeom::Transform3D::isNear
bool isNear(const Transform3D &t, double tolerance=2.2E-14) const
Definition: Transform3D.cc:208
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
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 LTI
Definition: merge-details.doc:119
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
used
When exceptions are the ZMthrow macro looks we know the try part will throw why not just consider how ZMthrow is typically used
Definition: whyZMthrowRethrows.txt:25
TODO
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 which will break no code But for pure rotations around coordinate axes and boosts along we do provide such methods as rotateZ and boostZ Here the efficiency difference is marked CLHEP has these explicitly We also must keep the technically superfluous rotate(delta, axis) and boost(3 doubles or 3-vector) methods. Split of .cc files I decided it might not be worth it TODO
Definition: merge-details.doc:59
Genfun::Mod::Mod
Mod(double y)
Definition: Mod.cc:9
axis
We have the boost methods returning HepLorentzVector &rather than so things can be chained we feel the boost methods along an axis
Definition: minorMergeIssues.doc:155
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
portability
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 portability
Definition: minorMergeIssues.doc:172
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
particular
We have the boost methods returning HepLorentzVector &rather than so things can be chained we feel the boost methods along an boostZ in particular
Definition: minorMergeIssues.doc:156
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
ee
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 ee
Definition: minorMergeIssues.doc:140
CLHEP::TimePositive
@ TimePositive
Definition: Geometry/CLHEP/Vector/LorentzVector.h:65
Classes
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 Classes
Definition: merge-details.doc:110
RotationY
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 RotationY
Definition: merge-details.doc:110
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
LT
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 one derives LT
Definition: merge-details.doc:121
setRThetaPhi
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 for setRThetaPhi(double r, double theta, double phi)
vectors
Methods applicble to containers of vectors
Definition: keyMergeIssues.doc:327
boostX
boostX
Definition: merge-details.doc:99
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
Genfun::Mod::operator()
virtual double operator()(double argument) const
Definition: Mod.cc:26
less
there is no the time needed for times is not significantly less
Definition: merge-details.doc:53
alone
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this alone
Definition: minorMergeIssues.doc:92
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
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
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
type
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 type
Definition: minorMergeIssues.doc:113
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
LorentzVectors
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 we will forego these and use the CLHEP implementations Methods acting on containers of LorentzVectors
Definition: minorMergeIssues.doc:162
keyword
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 keyword
Definition: minorMergeIssues.doc:139
zmpv::AxisAngle
CLHEP::HepAxisAngle AxisAngle
Definition: Geometry/CLHEP/Vector/AxisAngle.h:108
above
In the example above
Definition: mechanics_ZMx.txt:49
LorentzBoostY
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 LorentzBoostY
Definition: merge-details.doc:111
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
unit
exctest1 cc this occurrence arose from this associated compilation unit
Definition: mechanics_ZMx.txt:113
void
We should separate methods that force the load of the Rotation class For practical that implies that methods like and that as in the ThreeVector class we separate the cc files Also again we have the rotation methods returning HepLorentzVector &rather than void
Definition: minorMergeIssues.doc:148
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
Vector
HepGeom::Vector3D< double > Vector
Definition: testTransform3D.cc:20
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
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
example
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 for example
Definition: merge-details.doc:16
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
Here
Here
Definition: mechanics_ZMx.txt:81
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 &)
CLHEP::HepXHat
const Hep3Vector HepXHat
Definition: Matrix/CLHEP/Vector/ThreeVector.h:425
simplified
ZOOM classes Symbol which is defined in the SpaceVector h backward compatibility header This has the consequence that ThreeVector h is considerably simplified
Definition: merge-details.doc:9
enabled
When exceptions are enabled
Definition: whyZMthrowRethrows.txt:1
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
CLHEP::rotationOf
HepLorentzVector rotationOf(const HepLorentzVector &vec, const Hep3Vector &axis, double delta)
Definition: LorentzVectorR.cc:48
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
HepGeom::Transform3D::inverse
Transform3D inverse() const
Definition: Transform3D.cc:146
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
these
In these
Definition: minorMergeIssues.doc:21
phi
we want to make it possible for the user to use the so we provide a few new for double double phi
Definition: minorMergeIssues.doc:20
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
Genfun::Mod
Definition: CLHEP/GenericFunctions/Mod.hh:19
Y
Definition: testSharedPtrBasic.cc:34
CLHEP::HepZHat
const Hep3Vector HepZHat
Definition: Geometry/CLHEP/Vector/ThreeVector.h:425
like
When exceptions are the ZMthrow macro looks like
Definition: whyZMthrowRethrows.txt:13
axes
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 which will break no code But for pure rotations around coordinate axes and boosts along axes
Definition: merge-details.doc:56
s
Methods applicble to containers of as in std::list< LorentzVector > s
Definition: keyMergeIssues.doc:328
rotateUz
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 rotateUz
Definition: minorMergeIssues.doc:113
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
Genfun::Mod::~Mod
virtual ~Mod()
Definition: Mod.cc:17
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
s
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 we will forego these and use the CLHEP implementations Methods acting on containers of for list< LorentzVector > s
Definition: minorMergeIssues.doc:164
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
Besides
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 which will break no code But for pure rotations around coordinate axes and boosts along we do provide such methods as rotateZ and boostZ Here the efficiency difference is marked Besides
Definition: merge-details.doc:58
RotationZ
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 RotationZ
Definition: merge-details.doc:110
HepGeom::Rotate3D
Definition: CLHEP/Geometry/Transform3D.h:375
for
for(n=1 ;n< 98 ;n++)
Definition: JamesRandomSeeding.txt:34
itself
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 itself(independent). It must be done by generating some(selectable) number of deviates
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
reason
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 reason
Definition: minorMergeIssues.doc:111
others
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 others
Definition: minorMergeIssues.doc:118
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
et
double et()
necessary
At least for we will omit so as not to introduce template complications into CLHEP If necessary
Definition: minorMergeIssues.doc:168
x
any side effects of that construction would occur twice The semantics of throw x
Definition: whyZMthrowRethrows.txt:37
this
any side effects of that construction would occur twice The semantics of throw on the other are that x is not constructed an extra time The macro used achievs this
Definition: whyZMthrowRethrows.txt:41
purposes
We should separate methods that force the load of the Rotation class For practical purposes
Definition: minorMergeIssues.doc:147
include
include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules/ClhepOutOfSourceBuild.cmake) clhep_ensure_out_of_source_build() cmake_minimum_required(VERSION 2.6) project(CLHEP) set(VERSION 2.1.4.1) set(CMAKE_MODULE_PATH $
Definition: CMakeLists.txt:24
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
FUNCTION_OBJECT_IMP
#define FUNCTION_OBJECT_IMP(classname)
Definition: CLHEP/GenericFunctions/AbsFunction.hh:156
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
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
theta
we want to make it possible for the user to use the so we provide a few new for double theta
Definition: minorMergeIssues.doc:20
Test
Definition: testBug90848.cc:21
is
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
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
Mod.hh
Genfun
Definition: CLHEP/GenericFunctions/Abs.hh:14
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