[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reading NaNs
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,
| 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
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