| Date: Mon, 20 Feb 2012 11:01:29 -0500
 | From: John Cowan <cowan@mercury.ccil.org>
 | 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports