Re: Proposal for new Physics Vector classes in ROOT

We need to place the seminal email discussing the inheritance issue into a document because 50% of all physicists will be asking the same sort of question as Valeriy's second one. I'll do that when I can.

> Hi Lorenzo,
> this is my personal impression (ignore it).
>
> - First of all, the package lacks of "generality".
> Just glance at GenVector/GenVector/
> it contains too many (probably) "auxilary" classes like
> "EulerAngles", "CoordinateTraits" etc. why to show it to user?
>

EulerAngles (and AxixAngle) are in fact part of the user interface, so they must be shown.

It would be a good thing to hide CoordinateTraits in some manner. Choices include putting it in some sort of detail:: namespace so users can see it but know they don't have to pay attention to it, or putting the header itself into a different directory. I like the implementation-headers directory approach but it does mean adding that to the build structure. For now, until we decide, I'm leaving it as an ordinary header.

> - Throughout the code you are using templates (it's good and bad)
> why not to use templates and class inheritance with method overloading
> for classes like BasicLorentzVector, PositionVector3D etc. -
> they are all "vectors" and should be derived from a single base class.
>

Inheritance for the sole purpose of inmlementation convenience is a bad idea. Best practice is to avoid that; I have a note about that which I will make available.

See the comment at the top of this reply.

> - I do not see in the code *.cxx files. It is BAD to put the actual
> code only into header files.

Given that the classes are all templated, ultimately, off the Scalar type, we are somewhat FORCED to have the code in the header files (or in other included implementation headers). Also, much or most of the code is supposed to be inlined and again that must be in headers.

The consensus in the physics community seems to be that we should provide ways to store vectors as floats, and also as polar or cylindrical-eta form. (If I had to vote, I would vote to simplify by ONLY supporting doubles as the scalar type, but I'm pretty sure of my assessment that most users would ask for the extra flexibility.) Thus we are forced to put the code in the headers (or the equivalent, in .icc files).

Some complicated code in the Rotations classes will go into .cxx files.

>
> - totally the code contains ~2000 lines (without comments),
> most of them "just primitive assignments".
> This 2 days of work for professional programmer
> I'm afraid this is just another game which I/we saw at CERN for >10 years
> LHC++, Objectivity, Anaphe, Aida, Pi, Seal, Spi ... GRID!!! ...
> repressing ROOT.
> Spent a lot of money (rougth estimates it's hundreds of millions of
> Euros) and
> efforts, conferencing in "exotic places" without any usable output.
>

I'm not going to touch that comment about CERN software politics with a ten foot pole. But I will say that

• It looks like this stuff will be integrated with ROOT, not repressing ROOT (in fact P. Canal has explained to me some coding convention changes that we will make to be better ROOT citizens)
• This stuff is going to be real and delivered. The goal is to have version 1 usable by the end of June; I don't see us missing that goal by much, because the debates about design have NOT been turning into endless arguments, and because almost all of the tough issues and code implemntation gotchas have been thought through in the CLHEP context.

> Regards. Valeriy
>

Mark Fischler (630) 840-4339 Received on Thu Jun 09 2005 - 19:02:52 MEST