From: Andy Little (andy_at_[hidden])
Date: 2003-10-23 12:23:56
"Paul A. Bristow" <boost_at_[hidden]> wrote in message
> | -----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
> | 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
> unit, now that 'everyone' is using at least 64-bit doubles in their
> (which is enough to keep everyone except the astronomers in the exponent
> And the significand precision available (15-ish decimal digits) is ample
> physical measurements.
> Obviously 'everyone' excludes those like toaster designers who must
> 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
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
> 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
work (data acquisition... totally forgotten unless it goes wrong...sigh )
... Standards would be nice !
> Hopefully we can find a solution which caters for both.
(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
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:
My view is that the unit should be the type:
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:
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.
length local_distance = distance_to_target; // yawn.... must be in
// 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
using the second approach this is not a problem ... IF you have big enough
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk