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