Boost logo

Boost :

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-02-13 15:33:19


AMDG

Noah Roberts <roberts.noah <at> gmail.com> writes:

> Frankly put, I don't have a use for a library that does static unit
> conversions. We work in one system of units and convert into/out of
> those units when required to arbitrary units the user specifies and
> there are of course only a few dimensions we do this in. I have a hard
> time seeing a situation in which this isn't the way you would want to go
> about it.
>

As has been stated before, this library is primarily about
type safety. The conversions are a secondary concern.
>From what you are saying I think that you have not seriously
considered what the implementation should look like. There
are two basic possibilities

1) Store everything in some standard unit system and also
   store the conversion factor to the requested system.

2) Store the value in the requested unit system and remember
   the conversion factor to the standard system.

How should addition and subtraction be defined? You cannot
require that the operands have the same unit. Otherwise
harmless looking code such as
    1.0 * joules + (2.0 * kilograms * pow<2>(2.5 * meters / second)) / 2;
might not work. Converting the second to match
the first will work but loses precision. If you
use 2. to avoid the precision loss brought about
by the conversions involved in 1., by the time
you are finished you will end up losing more
precision than if you had simply converted to SI
to begin with.

Both of these require storing twice as much information
as the current implementation. The inefficiency is
probably more than a simple factor of two because the
size increase will most likely force the compiler to continually
load and store instead of keeping the values in a register.

Any more complex approach will add even more overhead.
For example, storing a sorted dimension list necessiates
a call to merge for every single multiplication or division.

In Christ,
Steven Watanabe


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk