Date: Sun, 29 Oct 2006 11:08:44 -0800
From: Per Bothner <per_at_bothner.com>
> I have two alternative proposals:
>
> 1) Allow eqv? and eq? to return either #t or #f if both arguments
> are NaNs.
> 2) Require eqv? to return #t if both arguments are NaNs.
> eq? would be permitted to return either #t or #f, as with all
> numbers.
I believe 2 is the correct solution for the "same NaN". If there
can be multiple NaN values (as specified by IEEE) then I think 1 is
right, but 2 NaNs that have the type and bit representation should
be eqv?.
One thing to keep in mind when discussing NaNs is that they might be
used to represent something completely different from numbers. For
example, on a 64-bit machine a Scheme implementation could use the NaN
space to encode every non-flonum object, with obvious performance
advantages for floating-point applications. (This particular use of
NaNs was envisioned by the IEEE floating-point designers, and should
be considered a real possibility. GJS has been asking for an
implementation with this property for years.)
The consequence of this is that there's no way to reason about what
NaNs should mean, because they can be used in essentially arbitrary
ways.
As for using their bit pattern for EQV?, I think that's pretty
arbitrary. The safest thing is to say that (eqv? x y) is unspecified,
but that (eqv? x x) should return #t. But the behavior of EQ? and
EQV? should _not_ be related to that of = and its like.
Received on Mon Oct 30 2006 - 21:59:17 UTC