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

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: reading NaNs*From*: bear <bear@xxxxxxxxx>*Date*: Thu, 27 Oct 2005 10:28:29 -0700 (PDT)*Cc*: a.watson@xxxxxxxxxxxxxxxx, tb@xxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051027164540.2B79C1B77BB@xxxxxxxxxxxxxxxxxxxxx>*References*: <20051021145326.816C11B77BB@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>

On Thu, 27 Oct 2005, Aubrey Jaffer wrote: > The precision available in NaNs is a hardware attribute. How can it > be settable? It seems that most current hardware supports several different 'widths' of floating-point numbers. Also, the concept of NaN is easily applicable to extended float types handled in software. > If program B reads lists, association lists, or vectors containing > numbers, then your approach must descend data structures looking for > NaNs -- all this effort for a case which shouldn't occur. Should this > input vetting also check for embedded end-of-file objects? See, I have a different problem. Suppose implementation A has a wider floating-point representation than that in implementation B, or bignums in vector indices (probably with a sparse-vector implementation underneath) and implementation B doesn't. When A produces a datastream for B to read, it may include a floating-point format of greater magnitude than B can read, or a vector whose indices exceed what B's can represent. So, deep down inside the reader, something returns a NaN, signals, and traps, with the reader returning the NaN. From the call site, the difference between this "live error" NaN and a NaN that has merely been read may not be obvious. Similar things are going to happen when one implementation supports the new decimal formats in IEEE-754R and has exact decimal floating-point constants, and another implementation doesn't, or whatever. We have to be able to tell the difference between a read error and a NaN result being correctly read. So if we're going to have a NaN read/write syntax, we *MUST* require implementors to guarantee that, no matter what, their reader will never throw an error and return a NaN. More generally, we have to have a defined behavior for what read has to do when it reads an object that cannot be represented in its own implementation - for example an IEEE-754R exact decimal float in data to be read by an implementation that doesn't use that representation. If it silently coerces all floats to inexact, the program may be incorrect as a result. Bear

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

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

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