En réponse à Gabriel Dos Reis <[EMAIL PROTECTED]>:

[snip]

> | On a more general side, please keep in mind that *signaling* NaNs are meant to
> | trap when used ("used" can be a simple copy, the standard leaves it
> | implementation-defined). 
> 
> They trap only when operands of arithmetic operations.

Please. When I wrote that it "can be a simple copy" and that it is
"implementation-defined", I meant it. Computer arithmetic is my everyday work;
whenever possible, I try to avoid making things up. Here is an excerpt of
paragraph 6.2 of IEEE 754 standard: "Whether copying a signaling NaN without a
change of format signals the invalid operation exception is the implementor's
option.".

> | If the user suddenly decides to put a signaling NaN in
> | a floating-point variable, she shouldn't be surprised if the program traps as
> | soon as it uses this variable. I don't understand why the interval library
> | should prevent such a behavior,
> 
> I'm not saying the interval library should prevent that behaviour.
> I'm syaing the interval arithmetic should not provide a trapping isnan
> function. That is a different matter.  

What don't you understand in the expression "isnan is a private function"? This
trapping isnan function is *not* provided to the user, it is an internal
function. It is only used inside interval arithmetic functions and it will make
these functions trap if given a signaling NaN argument.

Let's stop this discussion right now, it's going nowhere. I'm not arguing a
general purpose isnan function should trap when given a signaling NaN, because
it shouldn't. But in the particular case of the *internal* function of the
interval library, it is the *expected* behavior. Unless you can give a single
example where this behavior is not desirable for the users of the interval
library, I won't try any further to justify why the function was written the way
it is and not another way (and that was the reason that started this whole thread).

Regards,

Guillaume
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to