[fitsbits] INF/NAN as header values?

[William Pence]

Erik,

[I suspect that your previous post to FITSBITS never got distributed to 
the subscribers due to an internal list server configuration problem].

As you point out, keywords like the following are not valid according to 
the current FITS Standard:

DATAMIN = NAN  /  this is a Not-a-Number value
DATAMAX = INF  /  this is an infinity value

There are, however, several simple alternatives one could use that would 
be conforming.  In the case of NaNs, one could,

1) just don't write the keyword at all if it has no defined value, or
2) write it as a string, as in "DATAMIN = 'NAN'      ", or
3) write the keyword with a blank value field, as in "DATMIN =           "

(that 3rd case is discussed in section 4.2.1 of the standard).

In the case of INF values (which are less commonly used than NaNs), the 
only alternative that comes to mind is to enclose it in quotes as in

DATAMAX = 'INF'

Given these simple alternatives, I personally don't see a compelling 
need to modify the FITS Standard to support NAN and INF as valid 
floating point values.  My feeling is that any files that use this 
format should continue to be considered as not conforming to the 
standard, and further usage of this keyword format should not be encouraged.

Having said this, however, I was a bit chagrined to discover that my own 
CFITSIO library will read these non-comforming keywords without any 
complaints (at least when compiled with gcc), and returns the floating 
point representation of a NaN or INF, respectively. (CFITSIO does return 
an error if one tries to write these floating point values, however). 
This was not intentional on my part, and is a side affect of the fact 
that the gcc implementation of the 'strtod' function (which converts an 
ASCII string to a floating-point double value) supports strings like 
"INF" and "NAN".  A little research on the Web indicates that many 
compilers support this usage, but it is not universal.  One major 
exception is the Microsoft Visual C++ compiler, which apparently does 
not support this usage.  So CFITSIO's behavior is dependent on which 
compiler is used.  I should probably modify CFITSIO to close this loop 
hole so that it returns an error when trying to read these keywords.

One other comment: there are probably still computer systems around that 
don't use the IEEE floating point format for their internal machine 
representation of numbers (VAX VMS and some CRAY supercomputers were 
examples).  How to represent NANs or INFs on these machines is an 
interesting problem.

Bill

On 06/07/2013 11:22 AM, Erik Bray wrote:
> I originally sent this message a few months ago and never got any replies.  Now
> based on recent activity I'm thinking maybe the mailinglist was having issues?
> So trying again. Apologies if this is a duplicate.
>
>
> -------- Original Message --------
> Subject: INF/NAN as header values?
> Date: Mon, 8 Apr 2013 15:15:21 -0400
> From: Erik Bray <embray at stsci.edu>
> To: <fitsbits at nrao.edu>
>
> Hello all,
>
> I've had a few different issues reported against PyFITS lately regarding INF/NaN
> as values in FITS headers (that is, as float literals, without quotation marks
> around them).
>
> In particular, reading files that contain values like this fails in PyFITS, and
> writing those values to a header currently has undefined behavior (though upon
> writing to disk the header is reported as invalid).  And according to a strict
> reading of the current FITS standard, specifically section 4.2.4, this is
> correct:  INF and NaN are not valid formats for header values.
>
> I have a suspicion that this was at one time intentional--not all systems may
> have had representations for those values in their floating point
> implementations.  But by today's standards it feels like an oversight.  It was
> pointed out to me that IDL allows saving INF/NaN as header values, but the way
> it writes them violates the FITS standard.  But several such files appear to be
> present in the wild, so I'm considering going and letting PyFITS allow this too.
>
> Are there any thoughts/feelings on this?  Should this be corrected in a future
> version of the standard?
>
> Thanks,
>
> Erik
>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
>

-- 
____________________________________________________________________
Dr. William Pence                       William.Pence at nasa.gov
NASA/GSFC Code 662       HEASARC        +1-301-286-4599 (voice)
Greenbelt MD 20771                      +1-301-286-1684 (fax)