[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reading NaNs

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


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