[fitsbits] 64-bit integer comments

[William Pence]

Mark Calabretta wrote:
> While we're counting bits, I note that the precision of keyvalue data
> types is essentially undefined.  Specifically, I believe that most
> generic header parsers that encounter
> 
> PSRTIME =       88402115102000 / [us] Time since T0
> PULSENO =           9465023873 / Pulsar pulse number since T0
> 
> will pack them into 32-bit ints and lose essential precision.  The FITS
> standard is silent on this issue, perhaps it should address it also. 

Integer keyword values must fit within a 80-character header record, so are 
limited to 70 digits, or sign + 69 digits.  Integer 'I' columns in ASCII 
tables can have almost unlimited number of digits.  The FITS Standard 
doesn't further restrict the maximum allowed number of digits in these 
cases.  It's not really appropriate I think for the FITS Standard to make 
recommendations on how software should deal with such large integers.

While it is probably true that many existing software packages read integer 
keywords into a 32-bit ints by default, this will gradually change as 64-bit 
hardware and software becomes more common and perhaps as programmers become 
more aware of the need to support larger values.  FITS interface software 
like CFITSIO already supports reading FITS keywords into 64-bit int 
variables, so there is no technical reason to prevent generic software from 
always reading integer keywords into 64-bit ints.  As an example, I recently 
upgraded CFITSIO so that it internally stores values of the mandatory 
keyword values (e.g., NAXISn, PCOUNT, and GCOUNT) as 64-bit ints to support 
larger images and tables.

> ...and while on the subject, can anyone explain the purpose of "integer
> complex" keyvalues?  I assume these are defined purely for syntactical
> reasons and can always be stored as floating point complex values.

The FITS format was modeled on the available Fortran formats, and the 
Fortran complex constant is defined as "a pair or real or integer 
constants."  This could be viewed as a precedent in the current I*8 image 
discussion,  where FITS supported a data type because it was widely 
supported elsewhere, but without much obvious immediate astronomical 
application.

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