Re: [Chicken-users] EQV? and NaN

[Aleksej Saushev]

John Cowan <address@hidden> writes:

> Aleksej Saushev scripsit:
>
>> Two different NaNs are _not_ the same, and there exist at least two
>> different NaNs (signalling and quiet, see IEEE 754). Two different
>> signalling NaNs are _not_ the same, since they encode _different_
>> events.  At least the _may_ be different.
>
> You are correct in principle: however, C does not support signaling
> NaNs, and there is no portable way to turn on FP exception handling.
> When handing is off, all NaNs are in effect quiet.
>
> Nor is there any portable way to retrieve the other bits of a NaN,
> short of casting it to a 64-bit integer quantity.  Nor are there any
> guarantees as to what those bits might mean.
>
> So in practice there is only one NaN value.

IEEE P754 mandates at least one function to distinguish between
signalling and quiet NaNs and mandates proper sign interpretation for NaNs
(e.g. in copysign).

>> Given that "-nan.0" returns "+nan.0" this should be quiet NaN, right?
>> There may exist two different ways to get "+nan.0" and these may be
>> different per standard.
>
> Numerically all NaNs are unequal; that is, = always returns false when
> one argument is a NaN.  The question is what is the Right Thing to do
> when NaN is considered as a Scheme object.

Signal exception, as usual. What do you do when you apply "car" to an integer 
number?

In my opinion, if "eqv?" is meant to test "sameness," it should compare FPNs 
bitwise.
At least this won't affect numeric programs and will correctly detect same 
outcomes
which return same qNaNs.


-- 
HE CE3OH...