From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-06-15 03:17:38
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:
cin >> l; // in meters by default
cout << hyst_unit_manip << l;
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.
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.
the abstract_quantity_id is an implementation artefact that hides away
such things. In good Boost.Dimensional library rank and inversion
behaviour should be taken into account. It would eliminates bad smells
like the smell of torque in current PQS implementation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk