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

Functions | Variables
minorMergeIssues.doc File Reference

Functions

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
 
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
 
Signatures of Hep3Vector::rotate For equivalent rotate () methods
 
Signatures of Hep3Vector::rotate For equivalent ZOOM takes (axis, delta) where CLHEP takes(delta
 
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a rotate (delta, axis) method on a 3-vector in a very inefficent 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 angle (in itself quite a task) then douing vector *
 
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 rotate (axis, delta)
 

Variables

we want to make it possible for the user to use the so instead
 
we want to make it possible for the user to use the so we provide a few new methods
 
we want to make it possible for the user to use the so we provide a few new for example
 
we want to make it possible for the user to use the so we provide a few new for double theta
 
we want to make it possible for the user to use the so we provide a few new for double double phi
 
In these
 
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
 
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
 
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this alone
 
Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity Rotation
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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 =0. The ZOOM routine does check
 
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
 
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
 
We should separate methods that force the load of the Rotation class For practical purposes
 
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
 
We have the boost methods returning HepLorentzVector &rather than so things can be chained Also
 
We have the boost methods returning HepLorentzVector &rather than so things can be chained we feel the boost methods along an axis
 
We have the boost methods returning HepLorentzVector &rather than so things can be chained we feel the boost methods along an boostZ in particular
 
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
 
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
 
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< LorentzVectors
 
double m = s.invariantMass()
 
At least for now
 
At least for we will omit so as not to introduce template complications into CLHEP If necessary
 
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
 
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
 
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
 
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
 

Function Documentation

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

◆ is()

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

◆ rotate() [1/3]

We should separate methods that force the load of the Rotation class For practical that implies that methods like rotate ( )

Referenced by XF::Pow::operator()().

◆ rotate() [2/3]

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 rotate ( axis  ,
delta   
)

◆ rotate() [3/3]

Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a rotate ( delta  ,
axis   
)

◆ set()

we want to make it possible for the user to use the set ( )

◆ takes()

Signatures of Hep3Vector::rotate For equivalent ZOOM takes ( axis  ,
delta   
)

Variable Documentation

◆ alone

Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this alone

Definition at line 92 of file minorMergeIssues.doc.

◆ Also

We have the boost methods returning HepLorentzVector& rather than so things can be chained Also

Definition at line 155 of file minorMergeIssues.doc.

◆ 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 a routine can be passed a RI &and take axis

◆ 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 at line 115 of file minorMergeIssues.doc.

◆ 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 at line 115 of file minorMergeIssues.doc.

◆ 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 at line 171 of file minorMergeIssues.doc.

◆ 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 =0. The ZOOM routine does check

◆ example

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 example

Definition at line 20 of file minorMergeIssues.doc.

◆ 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 at line 158 of file minorMergeIssues.doc.

◆ instead

we want to make it possible for the user to use the so instead

Definition at line 19 of file minorMergeIssues.doc.

◆ 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 at line 139 of file minorMergeIssues.doc.

Referenced by CLHEP::RandFlat::restoreDistState().

◆ 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 at line 162 of file minorMergeIssues.doc.

◆ m

double m = s.invariantMass()

Definition at line 165 of file minorMergeIssues.doc.

◆ 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 at line 220 of file minorMergeIssues.doc.

◆ methods

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 methods

Definition at line 19 of file minorMergeIssues.doc.

◆ necessary

At least for we will omit so as not to introduce template complications into CLHEP If necessary

Definition at line 168 of file minorMergeIssues.doc.

◆ now

At least for now

Definition at line 167 of file minorMergeIssues.doc.

◆ 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 at line 109 of file minorMergeIssues.doc.

◆ 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 at line 118 of file minorMergeIssues.doc.

◆ 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 at line 156 of file minorMergeIssues.doc.

◆ phi

we want to make it possible for the user to use the so we provide a few new for double double phi

◆ 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 at line 221 of file minorMergeIssues.doc.

◆ 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 at line 172 of file minorMergeIssues.doc.

◆ purposes

We should separate methods that force the load of the Rotation class For practical purposes

Definition at line 147 of file minorMergeIssues.doc.

◆ 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 at line 111 of file minorMergeIssues.doc.

◆ 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 at line 113 of file minorMergeIssues.doc.

◆ 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 at line 102 of file minorMergeIssues.doc.

◆ 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 at line 102 of file minorMergeIssues.doc.

◆ Rotation

Signatures of Hep3Vector::rotate For equivalent ZOOM axis There is no harm in leaving this axis CLHEP has implemented a first forming an identity Rotation

Definition at line 95 of file minorMergeIssues.doc.

◆ 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 at line 164 of file minorMergeIssues.doc.

◆ 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 at line 30 of file minorMergeIssues.doc.

◆ these

In these

Definition at line 21 of file minorMergeIssues.doc.

◆ theta

we want to make it possible for the user to use the so we provide a few new for double theta

Definition at line 20 of file minorMergeIssues.doc.

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

◆ this

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 this

Definition at line 105 of file minorMergeIssues.doc.

◆ 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 at line 141 of file minorMergeIssues.doc.

◆ 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

◆ 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 at line 28 of file minorMergeIssues.doc.

◆ void

We have the boost methods returning HepLorentzVector &rather than void

Definition at line 148 of file minorMergeIssues.doc.

◆ 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 at line 141 of file minorMergeIssues.doc.