[boost] mcs::units informal review request

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-13 00:20:43

I've been making incremental improvements (I like to think, anyway)  
in the mcs::units dimensional analysis and unit library. The most  
recent version (v0.5.4, in the boost vault, just uploaded) includes  
wrappers for all <cmath> functions for which operations on quantities  
make sense, provides Boost.Serialization support for units and  
quantities, and a significantly expanded and more flexible system for  
unit conversion. I have also tightened up requirements on  
construction to improve safety in unit computations by making strict  
unit construction the default. In the hopes of getting it review- 
ready and addressing potential issues before the formal review, I'm  
hoping to get some concrete feedback from anyone who has downloaded  
and used the library (especially the v0.5.x branch).

To get things started, here are a few questions I have :

1) At the moment, the library enforces strict construction; that is,  
quantities must be fully defined at construction :

quantity<double,SI::length>	q1(1.5*SI::meters);

is acceptable, but

quantity<double,SI::length>	q2(1.5);

is not. Basically, construction of quantities (other than copy  
construction) is restricted to products/divisors of scalars and  
units, scalars and quantities, and/or units and quantities. This  
entails some redundancy, but also avoids errors in generic code where  
the unit system may change. In addition, I think it makes the intent  
of the code clearer. Direct construction from a value_type is  
supported, but through a static member function:

quantity<double,SI::length>	q3 =  
quantity<double,SI::length>::from_value(1.5);

Obviously, in my opinion, this sort of stuff should be restricted to  
libraries where it is necessary and shouldn't be ubiquitous in user  
code. I know that there is a camp in favor of implicit unit  
conversions (which can be supported in the library through a #define,  
though I think this causes more problems than it is worth), and I  
have some further thoughts on this below, but I'd like input from the  
non-implicit crowd as to whether this is a reasonable approach.

2) I'm not currently satisfied with the I/O aspects, particularly the  
lack of a mechanism for internationalization. I'd love to hear any  
design/implementation suggestions, especially from anyone familiar  
with facets/locales, on how to most gracefully accomplish this...

3) At the moment, it is possible to have completely generic rules for  
explicit conversion of quantities between systems by specialization  
of the conversion_helper class. The default implementation also  
allows simpler conversion implementations by defining the  
convert_base_unit template classes for each fundamental dimension  
(length, time, etc...) between the two systems to be  
interconvertible. I think it may be possible to implement a system  
that allows for fine granularity in implicit unit conversion; for  
example, SI::second and CGS::second are degenerate units, so they  
could be implicitly converted to one another with no computation.  
Thus, implicit conversion would be allowed in this case :

1.5*SI::seconds/SI::kelvin <-> 1.5*CGS::seconds/CGS::kelvin

since these are identical quantities, but not in this one :

1.5*SI::meter*SI::seconds/SI::kelvin <-/->  
1.5*CGS::centimeter*CGS::seconds/CGS::kelvin

Is this of sufficient interest to invest the effort?

4) Any comments on implementation from those brave enough to look at  
the guts of the library would be especially welcome.

Regards,

Matthias