Boost logo

Boost :

From: Marat Khalili (0x8.0p15_at_[hidden])
Date: 2007-07-09 16:50:21


At least someone else needs this feature if not implementation, that's

Kevin Lynch wrote:
>> 6. Correlations are not considered; instead, worst case is always assumed.
> Is there a use case where this behavior is useful and meaningful?

I do have this kind of case, but I don't know if it's typical or not. It
depends on: (a) how many independent sources of error do you have, and
(b) is it fine to have just upper bound for error. In my case I have few
numerical integrations (each producing inexact value) and various
operations on the results. I just wanted to be sure errors do not grow
too large. Every time I add uncorrelated values as correlated I'm wrong
by factor of two at most, and who can tell for sure if my integrations
are really uncorrelated or not.

> Without this feature, I can't come up with any reason for me to use it.

You can always write:
     z = inexact(
         x.value() + y.value(),
         sqrt(x.error()*x.error() + y.error()*y.error()))
in place of z = x + y where I really need it. Feature is just
formalizing it. Problem is, one might want to add x and z later.

Zeroth principle for me was, it is not opaque library, but just some
help with arithmetics. It will not allow person knowing nothing about
errors to calculate errors.

> 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.

It correctly produces upper bounds almost everywhere. Where it doesn't
(like cos(0.01 +- 0.1)) unexperienced physicist will also make a mistake :).

> 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).

No, I did need it myself, another question is I already spent more (like
x10 :)) time on the library than just doing it manually could take. So I
hope it will be of a use for someone else, that's why I need some
criticism, really.

> 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'd be happy to hear more about your experience.

> 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).

Yes, at the very least we would have to keep lots of correlations in
memory. N^2 correlations for N floating-point variables in the worse case.

> 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.

Well, it's an interesting idea - this can be done in Java with
reflection and runtime disassembling (Soot anyone here?). If only I had
some time... :(

> 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".

Was it in this list? Where can I take a look at the library?

> 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.

One day temptation to write a helper function or two becomes too strong :)

With Best Regards,

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