[boost] Re: physical quantities

From: Andy Little (andy_at_[hidden])
Date: 2004-06-15 09:06:22

"Alexey Nikitin" <reductor_at_[hidden]> wrote
> "Andy Little" <andy_at_[hidden]> wrote
> > The next version of my physical quantities libary pqs-1-01-04 is
> > available
> > on my site at:
> >
> > http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html
> >
>
> It is good library in my opinion.

Thanks .

> But what about angle, solid angle and
> concerned quantities?

I have been thinking about this and I hope I am starting to deal with it.
The first point to note is that the physical quantities  library can only
perform math on what I would call "anonymous" physical quantities, that is
quantities whose only real attribute(apart from units) is the signature
created by the dimensions of their base units. An immediate problem with
this is that some quantities are dimensionally-equivalent but are referring
to different quantities. Examples are torque and energy. In SI terms both
are represented in base units as:

kg.m+2.s-2

so in a calculation of force * distance , there is no way for the library to
know which quantity the programmer requires. As things stand currently I
have opted to make one named quantity the  "default", which in this case
would be energy so the output would be in joules. If the programmer requires
output in N.m  then a cast to a type representing torque is required:

 q_force::N F(1);
 q_length::m L(1);
 os << F * L << '\n';
 q_torque::N_m torque =  F * L; // ok implicit conversion to named
                                        // dimensionally equivalent  type
 os <<  torque << '\n';

produces :

1 J
1 N.m

However I have recently been thinking in terms of making any (ambiguous)
result of a calculation an anonymous quantity, so that the above result
would produce

1 kg.m+2.s-2     //  wish s/he would say Which quantity s/he wants
1 N.m                // Ok  its a torque.

In other words the programmer must explicitly state the required type by
means of a cast, so where  J  was required:

os << q_energy::J( F * L ) << '\n';   // ok  conversion to named but
                                        // dimensionally equivalent type

This is quite appealing because the idea of a "default quantity" has no
logical base. An anonymous quantity can be expressed easily (as above) and
this expresses more honestly what is actually going on underneath the
surface.

The relevance of this to angles and solid angles  is that the same approach
can be used. In any calculation whose result is dimensionless, the resulting
type would be an anonymous dimensionless quantity (ie a numeric type) ,
which is and will be represented in pqs by a numeric (ie (say) double).

It would seem appropriate that angles would be explicitly constructible from
a numeric type and implicitly convertible back again. This is based on the
fact that a radian  is just a number with extra attributes to distinguish it
for output purposes and extra constraints.

Despite the fact that angles are part of the S.I. base units I am not
intending to make angles part of the physical quantities classes in pqs, but
rather I hope to add a new type-family representing angles.
The angle type would have various purposes. First to help legibility, second
to provide scaling to/from numeric and other angle types and third to
provide units for ouput, finally to provide type safety in other operations
,which accept angles but not numerics (due to implicit conversion) in their
arguments. This seems appropriate. You can use angles in  operations
requiring numeric types (ie they lose their extra attributes ... "any number
is ok here"), but not the other way around ..."Sorry only angles allowed in
here". The angle type could also be used separately from the physical
quantities classes themselves. If that works I hope it can be applied
similarly to solid angle.

I hope to get this up and running in the next version to see how well it
performs in practise. I too need angles!

> Of course, I understand what exits very many other
> phisical quantities and it is impossible to include all them... but
> nevertheless?

Its a valid point and a big void in the library as it stands.

regards
Andy Little