Re: [boost] units review

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-04-05 09:05:51

Kevin,

I appreciate your efforts to get a review in under the wire - and  
fully understand the deadline phenomenon. This "labor of love" has  
expanded to take much more time than I ever intended, and I'm glad  
that at least a subset of prospective users like the end result...

> find the ability to define non-standard unit systems invaluable (I'm
> one of those "natural units for the problem" types ... CGS for E&M,
> solar mass/AU system for astrophysics, "hbar=c=1" for particle
> physics, etc).

If you ever get the chance to put a few of these systems together,  
I'd be happy to add them to the distro. I'm reluctant to do it myself  
because they are mostly outside the realm of my personal experience  
and I'd rather not screw them up... I think an extended set of CGS  
electromagnetic units (esu/emu/gaussian) with associated EM functions  
would be a great application of the library, since this is a clear  
case where getting units wrong can lead to big trouble.

> I'm not thrilled with the "quantity_cast" business, but my

In the sandbox version, quantity_cast is only used for the (unsafe)  
operation of direct mutating access to the quantity  
value_type...other uses have been removed.

> make useful comments.  Although I note that my favorite CODATA
> constant (Fermi's constant) is missing ... that itself is nearly
> inexcusable :-)

Ouch...I only left it out because NIST doesn't provide the SI value  
in their tables, just GeV... I'll get right on it ;^)

> I would like to see a warning on example 4 ... the presented
> "measurement error" type is insufficient for actual use in dealing
> with measurement errors, since it doesn't deal properly in
> correlations (quite a hard problem at compile time, I think):
> assuming x is a measurement<double>, with x.e the error, a correct
> error propagation would have
> (2x).e == (x+x).e == 2(x.e)
> whereas this class would get the addition wrong.  Additionally, it is
> not well protected against internal overflow in the various arithmetic
> operation.  But this isn't a review of "measurement<>", and it is
> overall still a nice toy example of the relevant library functionality
> and interface.

I'm actually thinking of including measurement<> with the library  
itself as a way to provide both physical constants and their  
associated measurement errors (from CODATA, in particular), so your  
comments are very timely. I was planning on tweaking the  
implementation, but I had naively failed to consider the issue of  
correlated errors... I'll have to see what's possible with a  
reasonable amount of effort. I certainly don't want to try to come up  
with a general solution for dealing with error covariances - any such  
solution would be messy and complex - but the self correlation case  
is clearly important... If you have any other ideas/input, it would  
be most welcome.

> Examples 14, 15 and 18 could use more discussion :-)  Particularly
> example 14, since the results seem to be highly dependent on the  
> quality
> of compiler optimizations.

This will be forthcoming. We will have substantial revamping of the  
documentation to do. Sigh.

Matthias