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