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:

aag
2011-07-11 13:24:56

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
2011-08-18 18:27:32

R6RS already requires this behavior.

cowan
2011-09-11 07:46:47
resolution␣␣
statusnewdecided

WG1 accepted this proposal.

cowan
2011-09-11 23:29:28
owneralexshinncowan
statusdecidedwriting
cowan
2011-10-08 04:16:40
resolution␣invalid
statuswritingclosed
cowan
2011-10-08 04:28:12
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.
cowan
2012-02-21 03:49:28

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
2012-04-09 22:13:54
statusreopeneddecided

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

cowan
2012-04-09 22:27:10
statusdecidedwriting
cowan
2012-07-15 01:19:12
resolution␣fixed
statuswritingclosed

Reopening yet again for conspectus on eqv?

cowan
2012-07-15 01:19:17
resolutionfixed␣
statusclosedreopened
cowan
2012-08-25 00:27:44
_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.

cowan
2012-08-27 07:04:38
statusdecidedwriting
cowan
2012-10-09 13:47:39
resolution␣fixed
statuswritingclosed