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.

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

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?

Regards,

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