Taylor Campbell wrote:
> I think it's
> pretty plain & straightforward that what NaN represents is not a
> number due to an undefined mathematical operation.  Can you elaborate
> on what you meant here?

The IEEE flonum standard precisely defines the conditions under which
NaNs are produced. For example, in conventional arithmetic, zero divided
by zero is not defined, but in IEEE flonum arithmetic, zero divided by
zero is defined to yield a NaN.

IEEE flonum arithmetic breaks with conventional arithmetic in a number
of areas (e.g., signed zeros, NaNs, and unique infinities) and does so
for reasons that make sense in the context of floating-point
calculations. If you want to simultaneously use conventional arithmetic
as a model for Scheme's arithmetic and take advantage of the IEEE
flonums provided by the hardware, then it is not surprising that you end
up with all sorts of contradictions.

It is quite possible to have a middle ground in which one uses
conventional arithmetic for exact operations and IEEE flonum arithmetic
for mixed or inexact operations. In this case, one would signal an error
for (/ 0 0) but one would silently return NaN for (/ 0.0 0.0). In such
cases, a reasonable interpretation of a NaN is that it is a value that
is just[*] as well defined as 1.0.

Regards,

Alan

[*] Okay, the precise bit pattern of the NaN is not defined, but it's
identity as a NaN is well defined.
--
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México