[r6rs-discuss] [Formal] Unclear how equality predicates behave on NaN

From: Paul Schlie <schlie>
Date: Mon Sep 25 22:08:15 2006

> John Cowan writes:
>> Marcin 'Qrczak' Kowalczyk scripsit:
>> (/ +0.0) => +Inf
>> (/ 0) => NaN
>> (/ -0.0) => -Inf
>>
>> I believe (/ 0) should be an error.
>
> I can see arguments both ways. Since -0 = +0 = 0, dividing by 0
> logically produces a projective rather than an affine infinity,
> but IEEE 754 lacks a representation for this. By applying the
> R6RS definition of NaN as a number so exact that it could even
> be (positive or negative) infinity, we get in some sense the
> Right Thing.
>
> On the whole, though, I think treating division by 0 as an error is
> better than relaxing the constraint that / with exact arguments
> always produces an exact result. The alternative would be to
> introduce an exact projective infinity (exact affine infinities
> are a Bad Thing, as explained in the SRFI-73 archive, because
> they make +0 and -0 distinct).

Although (/ 0) => run-time-exception may be the right thing for
a finite bounded set of -2^(N-1) to +2(N-1)-1 integers within
a finite field of N bits (as all encodings are spoken for).

However, as scheme's exact values are professed to have potentially
nearly unbounded precision, no such arbitrary encoding limitations
exist to justify defining that exact operations which exceed the it's
representational abilities are errors.

Rather, although less than perfect, it would seem imminently
better to define that the set of exacts include all exactly
representable values and NaN, thereby all exact operations may be
truly and consistently closed on that set, as IEEE 754 has attempted.

(where most ideally the set may further extended, and complemented
with an inherent exception handing mechanism where in circumstances
which may otherwise yield NaN may be directed to yield an alternate
value as may be prefered)
Received on Mon Sep 25 2006 - 22:07:09 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC