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