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.

R6RS already requires this behavior.

resolution␣␣

statusnewdecided

WG1 accepted this proposal.

owneralexshinncowan

statusdecidedwriting

resolution␣invalid

statuswritingclosed

resolutioninvalid␣

statusclosedreopened

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.

*same* bit patterns, rendering the above experiment mostly meaningless. This makes me inclined to the R6RS semantics.

statusreopeneddecided

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

statusdecidedwriting

resolution␣fixed

statuswritingclosed

Reopening yet again for conspectus on eqv?

resolutionfixed␣

statusclosedreopened

_comment0WG1 voted to make no change: the behavior of `eqv?` on procedures is explicitly unspecified.1345829336571305

statusreopeneddecided

WG1 voted to make no change: the behavior of eqv? on NaNs is explicitly unspecified.

statusdecidedwriting

resolution␣fixed

statuswritingclosed

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