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