[fitsbits] INF/NAN as header values?

[Erik Bray]

On 06/10/2013 02:30 PM, Steve Allen wrote:
> On Fri 2013-06-07T12:44:44 -0700, Tim Pearson hath writ:
>> I can think of no use-cases in which it would be appropriate for the
>> value of a FITS header keyword to be Inf: perhaps someone else can?
>
> I do not want to rule out that possibility, but I also do want not to
> break existing FITS readers.

Reviving this, as I was on vacation.  Here is one use case in which this issue 
was brought to my attention: https://github.com/astropy/astropy/issues/873

>> There are cases where the value NaN might be appropriate, but in
>> such cases I think it must be better to indicate ignorance by omitting
>> the keyword.
>
>> So I do not think keyword-values Inf and NaN should be added to the
>> FITS standard.
>
> We do have the concept of "null" or "undefined" header keywords; e.g.
>
> MYKEYWRD=       / absence of value after equals and before slash
>
> Rather than create files that violate the existing standard (and
> especially for mandatory and reserved keywords with defined data type)
> I would prefer writing a "null" value with a comment; e.g.
> MYKEY001=       / +Inf
> MYKEY002=       / -Inf
> MYKEY003=       / NaN
> For most situations simply writing a "null" value is already a strong
> flag that interpreting the value requires special care.

That would be fine, but it's still a hack that would have to be specially 
supported by the software in order to be useful.  In the meantime I've updated 
PyFITS to disallow setting inf/nan as header values.  I could say (and have 
said), "Well, headers that use the strings "INF" and "NAN" as keyword values are 
not valid FITS files so of course it should break."  That said, there are valid 
use cases for this and a convention should be agreed on and documented.

I think that systems like CRAY at this point should be the exception, and not 
the assumed consumer of modern updates to the FITS standard.

Erik B.