[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

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.



[*] 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