Re: [boost] [interval] unprotect &c.

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2005-12-08 13:23:37

Le jeudi 08 décembre 2005 à 07:33 -0500, David Abrahams a écrit :

> > Ideally, compilers should do this optimization themselves. 
> 
> Now I'm really confused.  What is the optimization, exactly?  It seems
> to say, "stop tracking computational error altogether," (as though you
> were using a plain double) but maybe that's not what you mean?  [read
> to the end; I may have figured it out]

The optimization is the elimination of dead reconfigurations of the
floating-point unit of the processor. Example:

  old = fpu_mode;
  fpu_mode = 1;
  ...
  fpu_mode = old; // --
  old = fpu_mode; // useless, the compiler should just remove it
  fpu_mode = 1;   // --
  ...
  fpu_mode = old;

Because compilers are unable to do this optimization, we provide a way
for the user to enable it manually by unprotecting interval types.

> > So, in the meantime, we have provided a way for the user to emulate this
> > optimization by manually deciding of program scopes where the rounding
> > mode is not changed and restored at each interval computation. 
> 
> Do you mean to say that the user delimits a region within which she
> knows using a single rounding mode for all intervals computation will
> yield correct results (I shouldn't have to guess -- the answer should
> be obvious from the docs)?

She doesn't have to know that much, she just has to know that she does
only interval computations in that block.

>  If so, why would that invalidate
> computation with ordinary doubles?  The rounding mode isn't normally
> changed by the compiler for ordinary FP calculation, is it?

Because the rounding mode isn't changed by the compiler for ordinary FP
computations, they will give unexpected results when executed in a block
where the interval library has taken over the floating-point unit.

> > I agree the documentation should be clearer. As long as the variable of
> > type I::traits_type::rounding is alive, then we are in a scope that is
> > protected. 
> 
> Now you're changing terms again.  I thought it was "unprotected!"

The interval types are unprotected. So they have to be used in a scope
that is protected. Otherwise computations with them would lead to wrong
results.

Default interval types are protected against an unadapted environment:
some code modifies the environment and restores it later on, so that the
library computes a correct result. But this protection is costly
performance-wise. So you unprotect these types to speed up the
computations that involves them. But as a consequence, you can safely do
these computations only in a manually protected block.

> > In such a scope, floating-point computations will have strange
> > behaviors, but computations involving unprotected intervals (they
> > run a lot faster than computations involving correct intervals) are
> > able to give correct results.
> 
> Because rounding for ordinary numbers is supposed to be
> "round-to-nearest" rather than "round up" or "round down" (at least
> one of which is needed for interval arithmetic)?

Right. The floating-point environment is set up at the start of the
program by the C runtime, and compilers generate code that expects this
environment to be untouched.

Best regards,

Guillaume