| Date: Mon, 20 Feb 2012 11:01:29 -0500 | From: John Cowan <[email protected]> | 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
