Re: [boost] [Review] Quantitative units - compile time vs runtime

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-03-28 14:40:47

On 3/28/07, Martin Schulz <Martin.Schulz_at_[hidden]> wrote:
>
> Since the library does not allow for mixed storage of quantities e.g. in
> vectors, further workarounds will be necessary when dealing linear
> algebra like BLAS, LAPACK or other advanced numerical libraries.

Wouldn't the run-time library suffer even more restrictions when it
came to BLAS, LAPACK, etc?  Those functions want a float or double
pointer that points to a contiguous array (the functions do not have a
stride parameter), as well as an array size.  quantity<abstract> will
have to be more than a simple value if you want mixed storage and
run-time conversions.  It requires polymorphism, or carrying around an
extra 'unit type' variable.

The run-time library does allow things like:

vector<quantity<abstract> > quantities;

but I really don't see how interfacing with BLAS, et. al. would be
possible directly.  The compile-time version, on the other hand, DOES
interface directly if the vector was full of say quantity<SI::length>
since those are simply doubles.

> Because the physical dimensions of all quantities are fixed ad compile
> time, there is no support for code that acts on certain quantities
> regardless of what these quantities actually represent, i.e. all
> quantities specified at runtime of the software. This includes GUI
> frameworks, post processing or visualization tools.

The current version does not preclude use with any of those.
Currently I have a GUI that accepts meters, nautical miles, miles, and
feet, depending on what the user wants to input his values in.  It
processes that input with other values gathered from various databases
(feet and nautical miles) and then displays the results to a window
rendering with OpenGL (so I had to convert the values to OpenGL
units).

> The library provides support for language-independent serialization by
> the use of Boost.serialization library. No attempt is made to ensure
> that the units of the deserialized quantities match the ones of the
> serialized ones.
>
> No attempt is made to provide formatting for quantities in human
> readable form (beyond debugging output).
>
> No attempt is made to provide parsing of unit input in human readable
> form."

I look at all of those as huge wins for this submission.  The can of
worms you open up when trying to solve the I/O issues with units and
locales is huge, and IMHO warrants a separate, interoperable
submission.

--Michael Fawcett