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: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------