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

From: Martin Schulz (Martin.Schulz_at_[hidden])
Date: 2007-04-02 17:15:29

> > 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.
> 
> Perhaps Boost.Any provides a solution to this issue? This 
> code compiles OK :

BLAS does not congest boost::anys. It crunches numbers. 
Bare-bone floating point numbers, in single precision and contiguous
memory 
for best performance. 

I like the picture of a conveyor belt for the transportation of my
quantities: 
Near the end of the belt, there is a last check that everything is in
correct 
shape (aka unit) and then - off it goes: Undressed of all other
attributes, 
the naked numbers get fed into that horrible numbercrunching monster
machinery. 
After getting out on the other side, they will get nicely dressed again
and 
released into the shiny world anew. :-)

Consequently, I consider a separation of concerns here: To the number
crunching 
monster, it should look like a POD floating point field. To the outside,
we need 
to dress these numbers with their further attributes. That could be done
by some 
proxy or facade object that models a quantity but only holds a reference
to the actual 
location of the numerical value instead of the numerical value itself.
Those proxy objects could be both either static or dynamic in nature,
just as needed. 

A separate object for each number, that would clearly incur a noticeable
overhead. 
To keep that manageable, it appears quite practicable to provide one
such object for
larger parts of the floating point field, implementing the usual
sequence semantics.

(More gentle minds do not feed those cute quantities to a monster, they
do perform a 
conversion into a dimensionless system beforehand.)

> Clearly, there is a limit to what one can accomplish when 
> converting between a data stream of raw bytes to a class. 

I would have expected an attempt to catch at least the major sources of
errors. 
Otherwise you end up with the same kind of vulnerability as the Mars
Climate Orbiter teams. 
This time, not on the level of subroutine calls but of files written by
on program and read 
by the another one. 

For an example, you could check whether the stringified unit of the
quantity that is to be 
deserialized is the same as the stringified unit of the quantatity that
has previously serialized. 
I.e. something along the lines of

template<class Archive,class Unit,class Y>
inline void serialize(Archive& ar,boost::units::quantity<Unit,Y>&
q,const unsigned int version)
{
    static std::string s1=stringify(unit<Dim,System>());
    std::string s2(1);

    ar & q.value();
    ar & s2;

    if (s1!=s2) throw incompatibilty_exception(q, s);
}

> Furthermore, the overhead involved in storing specific type 
> information on units and quantities could be significant, so 
> that storing a large array of quantities would occupy 
> dramatically more disk space than the corresponding array of 
> value types. 

Cleary, safety does not come for free. However in the case of a large
vector of 
quantities of the same type (the only one you considered so far), the
unit need 
to get checked only once for the whole vector, not repeatedly for each
and every 
element therein (much like the sequence semantics I mentioned above). 
That should alleviate the associated overhead sufficiently to get
manageable again. 

Yours,
        Martin.