Dear friends, I would just call the memnerfunction what it acually does : Jet.Get3Vector() In addition one could also access the scalar part of the 4-vector via Jet.GetScalar() and the Lorentz invariant via Jet.GetInvariant() Cheers, Nick. "Pasha Murat at (630)840-8237" wrote: > > Martin Weber wrote: > > > > Hi Pasha, > > > > using inheritance raises more problems than it solves, e.g. the dot > > product. Maybe you could make TVector3 a member of TLorentzVector: > > > > class TLorentzVector { > > Double_t E; // time / energy component > > TVector3 P; // space / momentum component > > .... > > }; > > > > This represents more the physical structure of TLorentzVector, which > > consists of a TVector3 and another component, and has the advantage not to > > create a temporary if you write > > > > TVector3 & TLorentzVector::Vect() { return P; }; > > > > I don't see a problem writing > > > > jet.Vect().DrEtaPhi(track) > > > > then. > > > > Martin > > Hi Martin, > > I also dont' see a problem with typing `jet.Vect()' and it is certainly true > that a > Lorentz vector needs a method returning a pointer/reference to its > 3D(space) component of type TVector3, which would just return a pointer without > doing extra work for free. I don't think though that Vect() is the best name for > it. > Suppose you have defined a jet which has its 4-momentum being a data member: > > class Jet { > TLorentzVector fFourMomentum; > } > > Immediately after defining an accessor function > > TLorentzVector& Jet::FourMomentum() { return fFourMomentum; } > > you find that > > jet->FourMomentum()->Vect() > > confusingly is a THREE-VECTOR.... One needs to think about the right name > here... > > I do not agree however that inheritance of TLorentzVector from TVector3 > introduces > ambiguities - this is a "developers" argument, not "users". I've been using 4- > and > 3-vector classes with 4-vector inheriting from 3-vector for a couple of years > and > didn't have any trouble with it, just conveniences. There is no *practical* > ambiguity > in the definition of the scalar (dot) product - see today's comments by Victor > Perevozchikov on this subject. > > Next, if you invert the order of the data members in your example > > class TLorentzVector { > TVector3 P; // space / momentum component > Double_t E; // time / energy component > .... > }; > > implementation-wise you'll get memory mapping very similar to what is provided > by > inheritance. This example also demonstrates an implementational problem: in > ROOT's world where everything is a TObject, both TLorentzVector and TVector3 > also > are TObject's. Practical consequence of this is that with the present > implementation > of TObject, which has non-static data members, you increase the size of your > 4-vector > by about 15% without any practical reason for it. If you have a lot of > 4-vectors, > 15% also counts. The "theoretical" side is that in case of 4-vector you don't > want > its space component to be an independent object with its own object ID and a set > of > access bits - there is just no way of using them. > > Summarizing, at present I see only advantages in the scheme where TLorentzVector > inherits from TVector3 and I'd really like to see a single example of where > inheritance of 4-vector from 3-vector creates a PRACTICAL ambiguity or > inconvenience, > which would complicate user's life. > -best, Pasha
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:42 MET