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