From: Matthias Schabel (boost_at_[hidden])
Date: 2007-04-05 09:05:51
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
> of compiler optimizations.
This will be forthcoming. We will have substantial revamping of the
documentation to do. Sigh.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk