Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk