From: David Abrahams (dave_at_[hidden])
Date: 2005-12-07 10:59:16
I find this in the documentation, which sounds self-contradictory:
> Unprotected rounding
> As explained in this section, a good way to speed up computations
> when the base type is a basic floating-point type is to unprotect
> the intervals at the hot spots of the algorithm. This method is safe
> and really an improvement for interval computations. But please
> remember that any basic floating-point operation executed inside the
> unprotection blocks will probably have an undefined behavior (but
> only for the current thread).
a. That doesn't sound "safe."
1. there's the potential undefined behavior.
2. there's the whole notion of "unprotect"-ing the computation.
Don't I lose the value of interval computation? That is, will
my computed results still reflect the potential error due to
floating-point precision limits?
b. How am I going to do any useful computation in an unprotection
block without doing any basic floating-point operations?
If it's not self-contradictory, could you explain what it means and,
if possible, improve the wording?
>From reading the docs, it's very unclear what optimization this
unprotection mechanism allows, and it's unclear when/how it's
mathematically valid to use the results (e.g. why not do all
computations that way if it's faster?) I get only a vague sense of
the answers to these questions from the docs. Yes, I read the Horner
example.
Finally, the use of the term "unprotection block" looks extremely
misleading. It looks like you have unprotected datatypes, but "block"
implies that there's a lexical scope within which unprotection is in
effect. There does seem to be such a notion for rounding mode (by
declaring an auto variable of I::traits_type::rounding), but not so
for unprotect. Unless I'm gravely confused, which is possible, in
which case, again, the docs need to be upgraded.
Thanks,
-- Dave Abrahams Boost Consulting www.boost-consulting.com