On Mon, May 7, 2012 at 5:31 PM, John Cowan <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
