EQV? and NaN

[cowan]

For good reasons, +nan.0 is not = to any other number, including itself. However, eqv? is about "sameness" rather than "equality". I propose that we add two clauses to the definition of eqv?, one saying that if both arguments are +nan.0, eqv? must return #t, and if one argument is +nan.0 and the other is not, eqv? must return #f.

All of my usual test Schemes already behave this way, with these exceptions:

• MIT, scsh, SigScheme?, Scheme 9 do not have non-finite numbers.
• Chicken returns #f if either argument is +nan.0.
• SISC returns #t if either argument is +nan.0.

[aag]

MIT Scheme does, in fact, have non-finite numbers, depending on the floating-point error mask that is set. This isn't documented, however.

[cowan]

R6RS already requires this behavior.

[cowan]

WG1 accepted this proposal.

[cowan]

We need to re-ballot this, because of the false claim that the "same" semantics that people voted for was equivalent to the R6RS semantics. Here are the new ballot positions:

Let nan and nan2 contain NaNs, possibly but not necessarily with different bit patterns implying different origins. In all cases, (eqv? nan x), where x is not a NaN, is required to return #f, assuming that (= nan x) returns #f for any x even in R5RS.

The R5RS semantics requires (eqv? nan nan) and (eqv? nan nan2) to return #f.

The R6RS semantics allows (eqv? nan nan) and (eqv? nan nan2) to return either #t or #f.

The "same" semantics requires (eqv? nan nan) and (eqv? nan nan2) to return #t.

The "same*" semantics requires (eqv? nan nan) to return #t and allows (eqv? nan nan2) to return either #t or #f.

I ran the following on my usual suite of Schemes on x86 Linux:

(define nan (/ 0.0 0.0))
(define inf (/ 1.0 0.0))
(define nan2 (- inf inf))
(list (eqv? nan nan) (eqv? nan nan2))

I confirmed that nan and nan2 expand to different bit patterns using Java's Double.doubleToRawLongBits method on the same system.

• Racket, Gambit, Guile, Kawa, SISC, Chez, SCM, Larceny, Ypsilon, Mosh, IronScheme, STklos returned (#t #t), showing that they do not distinguish between nan and nan2.

• Bigloo, Chicken, Chibi, Ikarus, KSi, Elk returned (#t #f), showing that they do distinguish. Chicken complains about division by 0.0, so I used +nan.0 and +inf.0 literals.

• Gauche, UMB, and VX returned (#f #f), following R5RS semantics.

• MIT, Scheme48/scsh, Scheme 9, Scheme 7, SigScheme, Oaklisp complained about the divisions by 0.0, and didn't provide any obvious workarounds.

[cowan]

Per Bothner points out that on his system (Java 1.7 on Fedora), nan and nan2 actually have the same bit patterns, rendering the above experiment mostly meaningless. This makes me inclined to the R6RS semantics.

[cowan]

The WG voted to leave the behavior of eqv? where both arguments are +nan.0 explicitly undefined.