Opened 6 years ago
Closed 4 years ago
#229 closed defect (fixed)
EQV? and NaN
Reported by: | cowan | Owned by: | cowan |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | WG1 - Core | Keywords: | |
Cc: |
Description
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.
Change History (14)
comment:1 Changed 6 years ago by aag
comment:2 Changed 6 years ago by cowan
R6RS already requires this behavior.
comment:3 Changed 6 years ago by cowan
- Status changed from new to decided
WG1 accepted this proposal.
comment:4 Changed 6 years ago by cowan
- Owner changed from alexshinn to cowan
- Status changed from decided to writing
comment:5 Changed 5 years ago by cowan
- Resolution set to invalid
- Status changed from writing to closed
comment:6 Changed 5 years ago by cowan
- Resolution invalid deleted
- Status changed from closed to reopened
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.
comment:7 Changed 5 years ago by 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.
comment:8 Changed 5 years ago by cowan
- Status changed from reopened to decided
The WG voted to leave the behavior of eqv? where both arguments are +nan.0 explicitly undefined.
comment:9 Changed 5 years ago by cowan
- Status changed from decided to writing
comment:10 Changed 5 years ago by cowan
- Resolution set to fixed
- Status changed from writing to closed
Reopening yet again for conspectus on eqv?
comment:11 Changed 5 years ago by cowan
- Resolution fixed deleted
- Status changed from closed to reopened
comment:12 Changed 5 years ago by cowan
- Status changed from reopened to decided
WG1 voted to make no change: the behavior of eqv? on NaNs is explicitly unspecified.
comment:13 Changed 5 years ago by cowan
- Status changed from decided to writing
comment:14 Changed 4 years ago by cowan
- Resolution set to fixed
- Status changed from writing to closed
MIT Scheme does, in fact, have non-finite numbers, depending on the floating-point error mask that is set. This isn't documented, however.