Marcin 'Qrczak' Kowalczyk scripsit:
> No, it's the negation of ==, and for two NaNs it is #t.
> < > <= >= for two NaNs are #f.
My mistake again.
> > However, we have more flexibility about the behavior of eqv? when both
> > arguments are flonums. It could return #f if either argument is a NaN,
> > as = does; or return #t iff the bit patterns being compared are the same;
> > or return #t if both arguments are NaNs, whether the bit patterns are
> > the same or different. (Chicken defers to =, and takes the first option.)
>
> The first choice is silly. Since the language is fortunate to
> distinguish equivalence and numeric equality, it's natural to make
> eqv? the finest equivalence relation which doesn't take the physical
> address of certain "value objects" into account. That is, 0.0 and -0.0
> are not equivalent but equal, NaN is equivalent to itself but inequal
> to itself, and 3 is not equivalent to 3.0 although numerically equal.
I don't agree that it's silly: I think implementations should be
allowed to adopt any of these.
> Distinguishing them leads to a simpler implementation:
Not necessarily. If the implementation language is C, then
it provides IEEE equality of doubles but does not provide bitwise
comparison of doubles as values (one must put them into a
union and compare them as char[8] arrays or some such).
> OTOH I see no practical utility in distinguishing these two kinds
> of NaNs. I'm not even sure whether it is specified which operations
> produce which NaNs.
IEEE 754 does not prescribe which NaN values are used for what.
> I would vote for allowing NaNs which are not eqv? if they have
> different bit representations, but each value, including a NaN,
> must be eqv? to itself.
Chicken provides that (eqv? x x) where x is a NaN is #t, but
(eqv? x y) where y is also a NaN is #f. That's probably because
eqv? implicitly invokes eq? first.
--
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
John Cowan <cowan_at_ccil.org>
Received on Wed Sep 20 2006 - 15:59:49 UTC