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