[boost] Re: Re: Physical Quantities revisited

From: Andy Little (andy_at_[hidden])
Date: 2003-10-23 12:23:56

"Paul A. Bristow" <boost_at_[hidden]> wrote in message
news:AHEJIHEOOOBMJPAGPLIPIELJEHAA.boost_at_hetp.u-net.com...
> | -----Original Message-----
> | From: boost-bounces_at_[hidden]
> | [mailto:boost-bounces_at_[hidden]]On Behalf Of Andy Little
> | Sent: Tuesday, October 21, 2003 2:22 PM
> | To: boost_at_[hidden]
> | Subject: [boost] Re: Physical Quantities revisited
> |
> | "Paul A. Bristow" <boost_at_[hidden]> wrote in message
> | > I have only expressed a view on one fundamental premise - that all
values
> | are
> | > held internally as SI units - but I may be wrong in this view.
> |
> | Within SI units there are various units within 1 dimension.
> | ie length has units from nanometres to kilometres (and beyond).
>
> I (and others) also expressed the prejudice that all are kept as their
base
> unit, now that 'everyone' is using at least 64-bit doubles in their
calculations
> (which is enough to keep everyone except the astronomers in the exponent
range.
> And the significand precision available (15-ish decimal digits) is ample
for all
> physical measurements.
>
> Obviously 'everyone' excludes those like toaster designers who must
struggle
> with much smaller (if any) floating point, ranges and precision.

They sure do.
    They have to deal with  temperature,  air flow (crumb build up),
bread... thickness, white, brown,humidity, warping, local heating.... and of
course crumpets.
All that usually with one crumby old  thermistor . though fuzzy logic has
been used with some success at the pricier end of the market !
(BTW toaster is actually a very good example. It deals with a large number
of  the types of dimensions .)
The consequences of improving their lot are huge...
If  the number of instances of burnt toast was reduced by 10%, the whole
western world might go to work 5% happier :-)

 For them, your
> solution is probably best, but for a more general purpose library like
Boost, it
> may not be preferred.

General purpose except for astronomers and embedded...
 the set of 'everyone' seems to shrink daily :-)
note : there may be a better  forum than boost for this subject ...?

 Bearing  in mind that you 'Big OS' guys generally rely on us to do your
dirty
work (data acquisition... totally forgotten unless it goes wrong...sigh )
... Standards would be nice !

>
> Hopefully we can find a solution which caters for both.

Yep.
(As an aside I hope we are discussing the same thing.
ie physics, physical quantities. Physics is just about big enough to deserve
its own personal entities. :-)
Sorry.. but my view is that generalisation to boxes of apples or types of
gasoline is really the road
to squish.)

I see  a "physical quantity" type as a concrete
type  like complex or BjarneStroustrup's Date
class in C++3rdEd.

A major  contention I think is the basis of the  type.
One view is that the dimension should be a type:

length mylength;

My view is that the unit should be the type:

length::metres mylength;

There is an argument in both directions...
Taking the spacecraft example (moving from kilometres to metres etc.)
At first this appears cleaner, using dimension as the type:
1)
length distance_to_target(10,"km"); // ok we're in km
 //...
    distance_to_target.use("m");  // ok we're in metres

 however now the programmer must interrogate the object, even with one
dimension its a mess:
    if (distance_to_target.units =="km")
       ...; //ok use km
else if  (distance_to_target.units =="m")
    // ok use metres.
..;
// but
length  local_distance = distance_to_target;        // yawn.... must be in
kilometres ...ooops
// ok ... could do automatic runtime interrogation and/or conversion... that
may be more important than
// absolute speed ... so that may be one way to go

/////
2)
using the second approach this is not a problem ... IF you have big enough
floats:
length<double>::metres  distance_to_target;
//...
length<int>::km     local_distance = distance_to_target; // ok

/////////////
Interestingly neither method is very satisfactory in the spacecraft example.
 In 1 the programmer must check the units on each use
there is no way to know the current the units without interrogation.
 The problems in 1 increase by powers when you have entities with multiple
dimensions  The second method
has units "in your face", however there is no run time way to change the
unit so you may run out of room in your distance_to_target variable.
ok could use two separate variables, a long range and a short
range... but that is not nice.
 You may be ok in 1 dependent on how you store the internal value, and  I
would assume that the best way
would  be at the scale of the unit. The unit tag has a useful purpose
at the expense of type safety or run time speed.

Of course with either method these problems could be solved by encapsulating
in a class...

however as a 'type' I would argue that 2 is more concrete and  typesafe than
1.
Andy Little
andy_at_[hidden]