Re: [boost] [rfc] Inexact quantities arithmetics

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
> 

<snip>

> 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:	[phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-361
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://budoe.bu.edu/~krlynch
-------------------------------------------------------------------------------