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

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

*To*: a.watson@xxxxxxxxxxxxxxxx*Subject*: Re: reading NaNs*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Thu, 27 Oct 2005 12:45:40 -0400 (EDT)*Cc*: tb@xxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <435EBC32.8010203@xxxxxxxxxxxxxxxx> (message from Alan Watson on Tue, 25 Oct 2005 18:13:54 -0500)*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <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> <20051024153539.D98031B77BB@xxxxxxxxxxxxxxxxxxxxx> <435D49E3.2010001 @astrosmo.unam.mx> <20051025224529.2760C1B77BB@xxxxxxxxxxxxxxxxxxxxx> <435EBC32.801020 3@xxxxxxxxxxxxxxxx>

| Date: Tue, 25 Oct 2005 18:13:54 -0500 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | | Aubrey Jaffer wrote: | > Having a universal read/write representation for arbitrary bit | > patterms prevents including information like the procedure | > causing the NaN in its printed representation. | | I don't see this. Can you elaborate? Suppose Scheme implementation X distinguishes NaNs by the procedure producing them and makes that information part of the printed representation for NaNs: (expt +inf.0 0) ==> #<not-a-number expt> (+ -inf.0 +inf.0) ==> #<not-a-number +> (/ (* 0 -inf.0) 3) ==> #<not-a-number *> (+ 5. (/ 0.0 0.0)) ==> #<not-a-number /> If R6RS has a universal read/write representation for arbitrary bit NaN patterns, then R6RS must assign bit patterns for all possible #<not-a-number {*}> syntaxes. If some future IEEE-754 hardware returns more than one NaN code, then its assignments are very unlikely to match the R6RS codes. Scheme has so far avoided arbitrary assignments of numbers to procedures. | BTW, I neither favor nor oppose reading or writing of arbitrary bit | patterns. I am favor of being able to specify the precision of the | NaN, though. The precision available in NaNs is a hardware attribute. How can it be settable? | > | However, I still think we need a read syntax. Suppose program | > | A calculates a value and writes it to a file and program B | > | reads the value from the file and uses it. Is is not useful | > | for program A to be able to communicate to program B that it | > | got a NaN? | > | > [...] | > | > If program A writes out its state, it would be useful to see that | > NaNs were computed. It gives operators a chance to capture the | > use case which provoked the error. If the program state is very | > valuable, then it can be repaired manually. | > | > But if program B reads its initial state from the file, its | > reading of NaNs puts errors into its state which can propagate | > and corrupt it. | | Um, how about program B doing: | | (let ((x (read))) | (if (nan? x) | (display "Help! Help! Program A is feeding me NaNs!"))) | | Sure, if you don't check your input, you can be screwed, but what's | new there? 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? One could use NaNs for all sorts of purposes. I think they are most useful when they flag impossible and unplanned-for numerical errors. As such, it removes this input vetting burden if an implementation is permitted to make NaNs unreadable. | Another example. Astronomical detectors tend to have a fair number | of bad pixels. We normally deal with these by associating a binary | "bad pixel map" with each image. The images are initially fixnums, | but after initial processing they are converted to flonums. It is a | lot simpler to simply replace the bad pixels in the processed | images with NaNs rather than continuing to work with the bad pixel | maps. I want to be able to archive processed images, so I need to | be able to read and write NaNs. (Okay, this is a bit of a cheat, | because the data are written in a binary format, but my point is | the same: reading a NaN is not necessarily an error.) If NaNs were used to signal bad pixels, then those NaNs would spread to neighboring pixels with certain types of signal processing steps. If you happened to employ Fourier transforms to do convolutions, then your entire image would become NaNs.

**Follow-Ups**:**Re: reading NaNs***From:*bear

**Re: reading NaNs***From:*Jens Axel Søgaard

**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:*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:*Alan Watson

- 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):