|
Boost : |
From: gmelquio_at_[hidden]
Date: 2003-07-26 00:17:04
En réponse à Gabriel Dos Reis <gdr_at_[hidden]>:
[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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk