This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 229: EQV? and NaN

2012-10-09 13:47:39
WG1 - Core
cowan
major
cowan
fixed
source
closed
2011-07-11 01:41:51
defect

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 Scheme does, in fact, have non-finite numbers, depending on the floating-point error mask that is set. This isn't documented, however.

R6RS already requires this behavior.

resolution
statusnewdecided

WG1 accepted this proposal.

owneralexshinncowan
statusdecidedwriting
resolutioninvalid
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.

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.

statusreopeneddecided

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

statusdecidedwriting
resolutionfixed
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
resolutionfixed
statuswritingclosed