Re: [boost] [Review][PQS] Review deadline

From: Andy Little (andy_at_[hidden])
Date: 2006-06-15 05:54:53

Hi Oleg,

"Oleg Abrosimov" wrote
> Janek Kozicki writes:
>> Andy Little said:     (by the date of Tue, 13 Jun 2006 00:59:11 +0100)
>>
>>
>>> t1_quantity type in PQS is overcomplicated. Two decisions complicated the
>>> design
>>> of t1_quantity. The first was the requirement to distinguish dimensionally
>>> equivalent quantities (torque and energy say).
>>
>> IMHO this distinguish is not that important. We only need units so that
>> compiler will check if there is any mistake in the formulas...
>>
>> Difference between torque and energy happens only during serialization
>> (print N*m, or print J ?), so maybe instead of complicated
>> abstract_quantity_id, there should be just some extra argument/setting
>> that will talk with serialization functions?
>>
>> Maybe this will make the design a bit leaner.
>>
>
> I'm completely disagree here.
>
> 1) Can anyone provide a really useful example of quantities with units
> encoded? I mean all these "length::m" things in PQS. There were requests
> to disable it and reduce to simple "length" and treat with units only in
> I/O with help of manipulators. Note that historical units can be handled
> in the same way:
>
> length l;
> cin >> l; // in meters by default
> cout << hyst_unit_manip << l;

The genesis of PQS was the need in my own work to remember which unit a floating
point variable was expressed in.
In this particular application the user had various data entry boxes where the
entry unit was millimeters. In my internal calculations I had to convert these
lengths to meters. Again I had to convert them back for output. I found I spent
a huge amount of time going back and forth between source files trying to
remember whether a particular variable was in meters or millimeters. You could
argue that the design of the application was poor but it was one of those
applications that grow from very simple beginnings by gradual additions into a
huge creaking monster. Users of the application often made requests to be
allowed to specify other units (feet and inches, meters etc) for data input too

I also had an email from a software house who needed to work in imperial units
for their work and had done some tests and found PQS potentially very useful for
their work.

Finally of course there is the famous example of the Mars Lander which crashed
wasting Millions of dollars, apparently  because one team was using metric and
the other imperial units.

There are countless other examples too.

> 2) torque is a really bad smell in PQS!
> it has the same dimension as an energy and, if I'm not wrong, is treated
> in the same way, so one can add torque and energy. It is a completely
> meaningless. There can not be meaningful equation that do that.  And if
> PQS allows it it means that it is broken here IMO.

Actually PQS works in terms of so-called anonymous quantities where only their
dimension and unit  is significant. The results of many calculations return an
anonymous quantity because I dont see any simple way to predict from the imput
variable what type the result should be.. The so-called named_quantities are
there for users who want to distinguish quantities for their own purposes. (the
obvious one being more satisfying output).

OTOH if you can come up with a way to  distinguish the result of force *
distance into either torque or energy depending on some criteria I would be
interested. FWIW I experimented with making torque have an angle ValueType. That
approach might be worth pursuing. My reason for not pusuing it was that I felt
that many potential users would simply find the extra complexity annoying ( as I
did during trying it out). And of course in the limit an angular velocity
(*radius) becomes a straight velocity etc, etc...

> the problem here is that PQS deals with only dimensions, but physical
> quantities have not only that, they have rank also.
>
> the difference between energy and torque is such that energy is a scalar
> and torque is a vector, or, more correctly, a pseudovector (it doesn't
> change its sign if space is inversed. velocity is a vector, it negates
> when space is inverted).
>
> it is completely wrong to add a scalar and a pseudovector (or vector).
> rank really matters! moreover, adding scalar with pseudoscalar or vector
> with pseudovector is meaningless too. such a summation can not occur in
> any correct equation.

Sure there is a lot of truth in what you are saying. What is lacking is a set of
rules that can be used to apply these principles. I believe that Matt Calabrese
was working on this aspect of quantities some time ago, so it might be worth
talking to him about it. I opted to stick to dimensional analysis checking only
and ignore other features of a quantity. I have enough on my plate as it is.

So I accept the criticism of PQS, but I believe a working implementation of what
you are describing will throw up difficulties (based on a small excursion into
that territory) that add a lot of complexity, nevertheless I would be interested
in at least some more details about how it would work in  practise.

It should be clear from the amount of input in this review that this field is
potentially huge and worthy of  much further research. The PQS library only
scratches the surface and leaves many gaps as you are saying. However my goal is
to keep PQS as simple as possible (IOW basically as it is now), but to tighten
up the documentation, add supporting classes (again a simple set as possible),
continue to look through the comments here, accept suggestions for syntax and
usability improvements etc etc, but not to extend into the territory you are
suggesting (largely as I keep saying because my maths and physics capabilities
simply arent good enough). It will then be up to others like yourself to
criticise and extend improve on, reject etc, etc PQS as part of that research.

regards
Andy Little