Boost logo

Boost :

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2007-07-09 15:03:02

Marat Khalili wrote:
> I. Some basic principles and limitations I established so far


> 6. Correlations are not considered; instead, worst case is always assumed.
> For example:
> (mx +- dx) + (my +- dy) gives ((mx + my) +- (dx + dy), not ((mx +
> my) +- sqrt(dx*dx + dy*dy);
> x *= x (where x is of inexact type) produces correct result, while
> x -= x will not produce 0 but, incorrectly, (0 +- 2*x.error()).
> In the distant future additional operations with correlations (and
> distributions) explicitly specified by user can probably be added.

Is there a use case where this behavior is useful and meaningful?
Without this feature, I can't come up with any reason for me to use it.
  I certainly can't see a use for it in publication quality basic
research or any engineering work where you need to rely on the errors it
calculates. Do you have an intended use case?

I don't want to sound too critical of your work (although it is hard to
NOT sound critical, I suppose ... sorry). I know how hard this area is
to do right. I've tried to build my own class to handle this type of
work and failed miserably. I've come to the conclusion that it isn't
even possible to do in pure C++ without substantial run time performance
penalties (although I would love to be proved wrong). The problem as I
see it is that proper error analysis requires a level of global
knowledge to which the language just doesn't give you access at compile
time. Now, maybe you could do it with sufficient compile-time
reflection/introspection support that interacts well with current
template metaprogramming facilities, but even then I'm not sure it can
be done. Perhaps you could write a compile-time DSL that does the right
thing, but then you aren't programming transparently in C++ anymore.

There was a brief exchange concerning this topic during the review of
the Quantitative Units Library back in the first half of the year.
Matthias Schabel was persuaded not to include his version of this class
in the library at the time since it didn't "do the right thing".

All that said, I would love to see an efficient library solution to this
problem ... I'd love to be able to use real C++ and not the current
poorly performing, hacky solutions that I have access to.

Kevin Lynch				voice:	(617) 353-6025
Physics Department			Fax: (617) 353-9393
Boston University			office:	 PRB-361
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA

Boost list run by bdawes at, gregod at, cpdaniel at, john at