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

*To*: a.watson@xxxxxxxxxxxxxxxx*Subject*: Re: reading NaNs*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sat, 29 Oct 2005 15:10:05 -0400 (EDT)*Cc*: tb@xxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <436131C2.8070003@xxxxxxxxxxxxxxxx> (message from Alan Watson on Thu, 27 Oct 2005 13:00:02 -0700)*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <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> <20051024153539.D98031B77BB@xxxxxxxxxxxxxxxxxxxxx> <435D49E3.2010001 @astrosmo.unam.mx> <20051025224529.2760C1B77BB@xxxxxxxxxxxxxxxxxxxxx> <435EBC32.801020 3@xxxxxxxxxxxxxxxx> <20051027164540.2B79C1B77BB@xxxxxxxxxxxxxxxxxxxxx> <436131C2.8070 003@xxxxxxxxxxxxxxxx>

| Date: Thu, 27 Oct 2005 13:00:02 -0700 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | ... | | I do think your suggestion of context is a good one, provided it is | optional and does not interfere with bit patterns. It can be | accomodated by: | | (a) "write" writes NaNs with a bit pattern and a possible context | (for example, #<NaN #x12345ef expt>). If the implementation does | not support context or if the NaN is not associated with any | context, "write" omits it (for example, #<NaN #x12345ef>). | | (b) "display" writes NaNs without a bit pattern but with a possible | context (for example, #<NaN expt>). If the implementation does not | support context or if the NaN is not associated with any context, | "display" omits it (for example, #<NaN>). | | (c) If a bit pattern is present, "read" produces a NaN with the | same bit patterm. This maintains read/write equivalence. | | (d) If no bit pattern is present, but a context is present, and if | the implementation supports contexts, then "read" produces a NaN | with the same context. This may be a different bit pattern as the | reading and writing implementations may encode the context | differently. | | (e) If neither a bit pattern nor a context is present, "read" | produces a contextless NaN. | | Basically, write/read would preserve bit patterns and display/read | would attempt to preserve context. What do you think? It looks a reasonable system for read/write invariance. I think there is a practical problem with "designer-NaNs" in that, unlike all other IEEE-754 number objects, they cannot be constructed by IEEE-754 floating-point operations alone. For example, SLIB/bytenumb.scm has R5RS code which converts between numbers and byte representations of IEEE-754 numbers. <http://savannah.gnu.org/cgi-bin/viewcvs/slib/slib/bytenumb.scm?rev=HEAD&content-type=text/vnd.viewcvs-markup> In an SRFI-70 compliant implementation with bignums and flonums, all single or double float numerical values are converted uniquely. But only one NaN value is converted because IEEE-754 operations provide no way to distinguish NaNs. Mandating more than one portable NaN value will necessitate non-IEEE-754 mangling of flonums. The ultimate extension of this idea is the NaN-based pointer regimes mentioned in SRFI-70 discussions: <http://srfi.schemers.org/srfi-70/mail-archive/msg00079.html> | > One could use NaNs for all sorts of purposes. I think they are | > most useful when they flag impossible and unplanned-for numerical | > errors. IEEE-754:1985 section 6.2: ... Quiet NaNs should, by means left to the implementor's discretion, afford retrospective diagnostic information inherited from invalid or unavailable data and results. | That's a valid opinion, but I do not share it. I use them quite | usefully to flag possible and planned-for events for which there is | no other good answer. Such reasonable disagreement is why R6RS should *not* specify a read or write syntax for NaNs. Implementations should be free to have read/write syntax for NaNs or not.

**Follow-Ups**:**Re: reading NaNs***From:*Alan Watson

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

**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

**reading NaNs***From:*Aubrey Jaffer

**Re: reading NaNs***From:*Aubrey Jaffer

**Re: reading NaNs***From:*Aubrey Jaffer

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

- Prev by Date:
**Re: NaN's** - Next by Date:
**Re: NaN's** - Previous by thread:
**Re: reading NaNs** - Next by thread:
**Re: reading NaNs** - Index(es):