[fitsbits] Some FITS ambiguities

[William Pence]

Paul Barrett wrote:
> 
> I have three questions about version 2.0 of the FITS standard that the
> NOST document doesn't appear to cover.

Here's my opinion:

> 1) What is the recommended procedure for handling a keyword value that
> is >4294967296 (i.e. a 32-bit unsigned integer), or similarly,
> >18446744073709551616 (ie. a 64-bit unsigned integer)?
>
> Note that in fixed format an integer can have 20 digits. If they are all
> 9s, the integer is greater than a 64-bit unsigned integer.  And in free
> format, integers can have 70 digits.  How are these numbers to be
> handled?  By a BCD library?

The FITS Standard does not restrict the range of integer keyword values, so you can write
as many digits as will fit on the line (70).  It is then an implementation detail as to
how such large values should be handled by FITS reading software.  This will probably vary
from application to application.

> 2) What is the practical difference between a null string (i.e. '') and
> a blank string (i.e. '        ')?  See page 16 of the FITS standard.
> They are both strings. Does it really matter if one has 8 spaces and the
> other 0 spaces?

Conceptually at least, there is a difference between the two:  a null string ('') is a
string that has a null or undefined value.  A blank string on the other hand has a defined
value that consists of a sequence of blanks.  The Standard says that trailing blanks are
not significant, so I would interpret the first blank to be significant and any following
blanks to be insignificant (others might disagree with this interpretation however). The
distinction between null and blank strings may be lost in some languages (e.g. Fortran 77)
which do not naturally support the concept of a null string.   A keyword should be given a
null string value if the value is unknown at the time of writing the keyword, but may be
possibly  updated at a later time with a known value.  A blank string should be used if it
is known that the string is blank (e.g. if a keyword gives the middle initial of the
observer, then it should be blank if the observer has no middle name, and null if it is
not known whether the observer has a middle name).  In practice, I doubt if this
distinction is very important, except in certain special applications which might want to
use it.

Note that there is yet a third case in which a keyword can have no value, e.g.

RVALUE  =                  / comment field

In this case the datatype as well as the value of the keyword are both undefined (unless
the keyword is specifically defined to have a certain datatype in the Standard).

> 3) The FITS standard notes that a series of digits with leading zeros is
> considered a decimal number, not an octal number as found in many
> programming languages.  (Kind of a shame really.)  The FITS standard
> does not note whether this is also true for floating point numbers.  Can
> floating point values contain leading zeros?

Yes.  The Standard does not explicitly mention this case because there is little ambiguity
about how to interpret the value of floating point numbers containing leading zeros,
unlike the integer case.

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