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

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-28 14:54:39

Martin,

Thanks for your comments.

> But this one does not live up to my personal expectations raised by  
> that
> introduction. This is clear to me, but I am afraid others may take  
> some
> time to discover that fact the hard way. Maybe the not the library,  
> but
> just the expectation is wrong. To avoid such misconception, please  
> give
> your potential users the chance to adjust their expectations  
> beforehand.

This is a good suggestion; as you point out, there is no benefit in  
having the expectations of potential users set beyond the scope of  
problems that the library actually addresses. I will add a clarifying  
section on "Domain of application and restrictions" to the  
documention as you suggest.

> 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 :

     boost::numeric::ublas::vector<boost::any> v(3);

     v(0) = boost::any(quantity<SI::length>(3.0*meters));
     v(1) = boost::any(quantity<SI::mass>(3.0*kilograms));
     v(2) = boost::any(quantity<SI::time>(3.0*seconds));

I honestly don't know how frequently the problem of containers of  
heterogeneous quantities will arise, but I understand that there may  
be situations where this is the case.

> 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.

Clearly, there is a limit to what one can accomplish when converting  
between a data stream of raw bytes to a class. 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. This problem is a general one,  
anyway : I don't know of any Boost libraries that provide type  
checked serialization.

> No attempt is made to provide formatting for quantities in human
> readable form (beyond debugging output).

At present this is true. However, I believe that extending the  
formatting options is a reasonable request and will be given serious  
consideration for future incarnations of the library. This would  
include IO manipulators and facets to control human language  
dependent output.

> No attempt is made to provide parsing of unit input in human readable
> form."

This is true at present. Since, as you already are aware, the unit  
must be specified at compile time, this would provide minimal utility  
at present. However, we would be delighted to work with you to ensure  
compatibility and interoperability  if you are interested in  
implementation of a library for handling runtime units.

Ultimately, as many if not most participants in Boost are volunteers  
doing the work on their own time, expecting complete solutions of  
significant problems like those posed by units to be provided in  
monolithic form, I believe, will just end up preventing anything at  
all from being accomplished in the problem domain. Ultimately, the  
process functions best via collaboration, with multiple individuals  
contributing their expertise to solve problems within their domain of  
experience and interest.

Regards,

Matthias