[ROOT] Re: AW: TLorentzVector revisited

From: Martin Weber (Martin.Weber@cern.ch)
Date: Sat Jun 10 2000 - 15:22:44 MEST


Hi,

sorry for the late answer, but I was quite busy during the last time.

> Martin,
> 
> 1) send me your setters and I will put them into TLorentzVector...

Here is the setter for spherical coordinates:

void TLorentzVector::SetRhoPhiThetaT(Double_t rho, Double_t phi, 
				     Double_t theta, Double_t t)
{
  // set TLorentzVector in spherical coordinate system, and time 
  SetXYZT(rho * TMath::Cos(phi) * TMath::Sin(theta),
	  rho * TMath::Sin(phi) * TMath::Sin(theta),
	  rho * TMath::Cos(theta),
	  t);
}

for TVector3 the same applies without the "t". Next topic:

> 2) instead of the named constructor idiom it is possible to add a coordinate
> system flag
>    eg: TVector3 v(rho,phi,theta,kSpheric)
> Comments?

1) It is backward compatible

2) It could be faster than the named constructor idiom, if we don't have
   too many coordinate systems, else the switch() takes too long. I know
   of four coordinate systems that should be supported in TLorentzVector
   - cartesian
   - cylindric
   - spheric
   - pt eta phi
   Speed also depends on how good compiler optimizations are.

   I could do some tests on speed difference on HP, IRIX, PC (Linux)
   if you would appreciate it.

3) It is less readable than the named constructor idiom.
   E.g. how to read the constructor 
   TVector3::TVector3(Double_t x, Double_t y, Double_t z,
                      Coordinate_t coord = kCartesian)

   in the case of a spherical coordinate system? Where to put phi? As x?
   Or as y?
   Documentating this without confusing the user isn't that easy.

1) is the same for both,
3) favors the named constructor idiom,
2) is unknown in the impact on data analysis.

Concluding, I'd make the decision after seeing the speed difference.

Best regards,

Martin



This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:27 MET