[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] multiple NaN values
| Date: Mon, 20 Feb 2012 11:01:29 -0500
| From: John Cowan <cowan@x>
| Per Bothner scripsit:
| > If there are multiple NaN values, they are all =.
| This is not the case: NaN is not = to any number, not even NaN.
NaN != NaN was a cute hack by FPU designers to avoid adding an opcode
for detecting NaNs. It has no standing mathematically. We should not
confuse IEEE-754 with Real Analysis.
(eq? +nan.0 +nan.0) in SCM, so (= +nan.0 +nan.0). Either that
behavior or signaling an error (because +nan.0 is not a complex
number) would be acceptable for SCM. Does R7RS permit an
implementation to behave in one of these ways?
| > However, the eqv? function is permitted (but not required)
| > to return #f when given two different NaN values.
| This is the subject of http://trac.sacrideo.us/wg/ticket/229 , which
| will be part of the upcoming fifth ballot.
A related issue:
The argument prototypes for <, <=, >, and >= are x1, x2, ..., meaning
that they are restricted to real numbers. 1+3i and NaN are not real
numbers, so my reading is that an implementation is allowed to signal
an error for these arguments.
In SCM, <, <=, >, and >= signal an error when passed a NaN argument.
This behavior is a happy medium between immediately signaling an error
whenever a NaN would be produced and allowing programs to run rampant
with NaNs, destroying any clue as to where in the program the
*unexpected* NaN was produced. Experience debugging Fresnel equations
in FreeSnell drove this design.
Is the behavior of SCM's inequalities allowed by R7RS?
Scheme-reports mailing list