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

*To*: a.watson@xxxxxxxxxxxxxxxx*Subject*: reading NaNs*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Mon, 24 Oct 2005 11:35:39 -0400 (EDT)*Cc*: tb@xxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <435C9A65.7060106@xxxxxxxxxxxxxxxx> (message from Alan Watson on Mon, 24 Oct 2005 03:25:09 -0500)*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <20051021155906.GC16464@NYCMJCOWA2> <Pine.LNX.4.58.0510210910130.18969@xxxxxxxxxxxxxx> <20051022011713.1F22A1B77BB@xxxxxxxxxxxxxxxxxxxxx> <87vezqmjkq.fsf@xxxxxxxxxxxxxxxxx> <20051022232548.5A2971B77BB@xxxxxxxxxxxxxxxxxxxxx> <873bmtxdnm.fsf@xxxxxxxxxxxxxxxxx> <20051023181854.4E7DD1B77BB@xxxxxxxxxxxxxxxxxxxxx> <871x2cowe8.fsf@xxxxxxxxxxxxxxxxx> <20051023195403.A50AF1B77BB@xxxxxxxxxxxxxxxxxxxxx> <435BEC21.60509@xxxxxxxxxxxx> <20051023205012.BFD241B77BB@xxxxxxxxxxxxxxxxxxxxx> <87zmoz27dg.fsf@xxxxxxxxxxxxx> <87hdb7kgmk.fsf@xxxxxxxxxxxxxxxxx> <87k6g3zw34.fsf@xxxxxxxxxxxxx> <871x2bkfj7.fsf@xxxxxxxxxxxxxxxxx> <8764rnu45b.fsf@xxxxxxxxxxxxx> <87br1fiv26.fsf@xxxxxxxxxxxxxxxxx> <87ll0jpu0q.fsf@xxxxxxxxxxxxx> <20051024022744.6CA581B77BB@xxxxxxxxxxxxxxxxxxxxx> <87veznbb37.fsf@xxxxxxxxxxxxx> <8764rnbaqr.fsf@xxxxxxxxxxxxxxxxx> <435C9A65.7060106@xxxxxxxxxxxxxxxx>

| Date: Mon, 24 Oct 2005 03:25:09 -0500 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | | NaNs are atoms -- they have no context or stucture, just a single | value. In an implementation which boxes flonums, NaNs aren't a single value; EQ? and EQV? are *not* guaranteed to return #t given two NaNs. [Read-sytnax for singular objects is useful because it allows those objects to be put in CASE clauses. But this works only for objects which match under EQV?.] | With the understandable exception of the eof object (and as has | been noted, this is exception is not universal), Lisps and Schemes | tranditionally provide read syntax for atoms. Closures and continuations are atomic; R5RS provides no way to deconstruct them. Yet every implementation I have encountered has a write syntax without a corresponding read syntax for them. | So, tradition suggests that we should have a read syntax for NaNs. Are you suggesting a single NaN or multiple distinct NaNs? To support existing IEEE-754 hardware, R6RS must not mandate multiple distinct NaNs. But specifying a singular NaN prevents implementations from fully supporting IEEE-754 in the future. Thus R6RS should declare that NaNs are numerical error-objects [or condition-objects, whatever], and leave the rest to implementations. We worked through this issue in SRFI-70. I think SRFI-70's treatment is Schemely, compatible with IEEE-754, and doesn't unnecessarily constrain implementations: The notation 0/0 is used within this report to designate a numerical error-object. A numerical function may return such an object when no other number (including real infinities) is the correct value. An implementation may report a violation of an implementation restriction in any calculation for which the result would be 0/0.

**Follow-Ups**:**Re: reading NaNs***From:*Per Bothner

**Re: reading NaNs***From:*Marcin 'Qrczak' Kowalczyk

**Re: reading NaNs***From:*Alan Watson

**Re: reading NaNs***From:*Alan Watson

**References**:**arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*John.Cowan

**Re: arithmetic issues***From:*bear

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Jens Axel Søgaard

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Alan Watson

- Prev by Date:
**Re: Testing the reference implementation** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: reading NaNs** - Index(es):