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?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.
| 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?
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.)
Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México