| Date: Sat, 29 Oct 2005 14:21:38 -0700
 | From: Alan Watson <xxxxxx@astrosmo.unam.mx>
 |
 | Aubrey Jaffer wrote:
 | > 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.
 |
 | Yes, you have to twiddle bits, but that isn't difficult.

Which bits do you twiddle so you don't spoof the hardware generated
NaNs?

This is platform dependent, even among IEEE-754 platforms.  As far as
I can tell, IEEE-754 implementations can vary widely in the number of
NaNs which are signaling versus silent.  How many silent NaNs you can
guarantee us for all flonum platforms?

 | > 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.
 |
 | Notice that using NaNs for unavailable data is explicitly mentioned.
 |
 | >  | 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.
 |
 | I very much disagree with your logic.  I agree that "NaNs appearing
 | in input always signal an error" is a valid point of view in that
 | it has an internal consistency and is not pointless.  However, it
 | flies against the spirit of the standard, as I see it, and against
 | practice in other languages, and eliminates other uses of NaNs.  I
 | think it is quite reasonable that R6RS should decide that your
 | opinion is valid but not the one it wishes to support.

Leaving NaN syntax unspecified does not prevent implementations from
putting NaNs to any use.

Many behaviors are left unspecified by R5RS, such as when operations
on exacts would produce results not representable as exacts; and
division by zero; and multiplication by exact zero; and syntax for
EOF.

 | You talked about a program writing a data base and then re-reading
 | it.  You said you wanted it to throw an error if it read a NaN.  If
 | you want to keep NaNs out of your data base, then surely a NaN that
 | is in the data base before writing is as dangerous as a NaN in the
 | data base after reading.  In that case, you have to arrange to keep
 | NaNs from ever entering the data base, so NaNs should never be
 | written, so NaNs should never appear be read.  So I would suggest
 | that your example is invalid.
 |
 | Basically, signalling an error on reading a NaN might significantly
 | help when:
 |
 | (a) Reading data written by another program.  Data written by a
 | human will have to be validated anyway.
 |
 | (b) NaNs were valid or not dangerous in the writing program but
 | invalid or dangerous in the reading program.
 |
 | Can you give me a real example that satisfies these constraints?

Suppose we read data from a spectrometer, then compute the average of
each pair of adjacent values and write it out.  None of the values
should be infinite.  But if somehow a positive infinity and a negative
infinity were adjacent, the average would be a NaN, which would be
written out.

The probability of this happening is so remote that writing checks for
it borders on lunacy.  But stuff does happen -- I would like my
implementation to choke when reading those NaNs.