On Mon, May 7, 2012 at 5:31 PM, John Cowan <cowan@mercury.ccil.org> wrote:
>
> That turns out not to be the case.  In R6RS we are explicitly told tht
> (eqv? +nan.0 +nan.0) => undefined, yet the two instances of +nan.0 are
> operationally equivalent in terms of standard R6RS procedures.
>
> ...
>
> I believe that they are not: no R7RS (or R6RS, for that matter) standard
> procedure can distinguish between one NaN and another.
>

I beg to differ. Consider the functions:

(define (flonum->list x)
  (define bv (make-bytevector 8))
  (bytevector-ieee-double-native-set! bv 0 x)
  (bytevector->u8-list bv))

(define (list->flonum l)
  (define bv (u8-list->bytevector l))
  (bytevector-ieee-double-native-ref bv 0))

These functions are composed entirely of R6RS standard library
functions, and the first (flonum->list) returns a list of bytes in a
flonum. If we take a nan with a low bit set (assuming little-endian):

(define nan0 '(0 0 0 0 0 0 248 127)) ; this is (flonum->list +nan.0)
(define nan1 '(1 0 0 0 0 0 248 127)) ; this is +nan.0 with a low bit

Then (eqv? (list->flonum nan0) (list->flonum nan1)) would be true
without OE, but since (eqv? (car nan0) (car nan1)) is false, this
would imply that the two NaNs are not OE. In other words, that the
first eqv? above would return false instead of true.

In conclusion, I believe that if we take the operations to be those of
R6RS, then the two NaNs are not OE, but if we take the operations of
R7RS so far, then the two NaNs are OE.

Regards,
Andrew Robbins

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports