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

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: reading NaNs*From*: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>*Date*: Thu, 27 Oct 2005 13:00:02 -0700*Cc*: tb@xxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051027164540.2B79C1B77BB@xxxxxxxxxxxxxxxxxxxxx>*Organization*: Centro de Radioastronomía y Astrofísica UNAM*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>*User-agent*: Mozilla Thunderbird 1.0 (X11/20050317)

Aubrey Jaffer wrote:

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

Agreed.

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 forNaNs -- 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.

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.

Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México

**Follow-Ups**:**Re: reading NaNs***From:*Aubrey Jaffer

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

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