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

Re: external representations

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



From: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>
Subject: Re: external representations
Date: Tue, 21 Jun 2005 11:58:05 -0500

> On Jun 21, 2005, at 11:18 AM, William D Clinger wrote:
> 
> > Aubrey Jaffer wrote:
> >
> >> SRFI-70 mandates no connection between IEEE-754 NaN and 0/0.
> >
> > No one said it did.  In the discussion of SRFI-70,
> > however, Bradley Lucier proposed having external
> > representations for NaNs.  I was responding to
> > Lucier's proposal as much as to yours.
> 
> Re: Your idea of representing common Scheme values as NaNs.
> 
> I believe it is possible under IEEE 754 that the "hardware" could 
> return a different NaN for each execution of (/ 0. 0.) in the code (for 
> example).  (Some proposals have suggested putting the address of the 
> code and/or a rough time stamp in the mantissa.)  I'm a bit concerned 
> that a floating-point operation could return a value that would be 
> interpreted by your scheme as #\C (for example).

Actually, there was a Lisp implementation that used NaNs to
encode other types of data.  It improved floating point
handling performance greatly, but they found that there's a
tiny possibility that an unexpected NaN pattern can be produced
as the result of operation, and gave up the implementation.

I'm contacting the guy who implemented it to ask the details,
but I guess it's what you described.

--shiro