64-bit integers in FITS

[Peter Bunclark]

Isn't the fundamental point that FITS is a data-interchange medium?
Hence, if someone happens to have 64-bit data, they will have a need
to move it between machines and would probably prefer to have used
FITS.  It's certainly not in FITS's remit to declare to
instrumentatation
groups that they are not allowed to invent 64-bit detectors.

Such a hypothetical group would have to invent a cooked-up data 
format of their own;  if it was me I'd put BITPIX=64 in the knowledge
that everyone would know exactly what I meant.  Why not enshrine it
in the standard, perhaps with the advice to use it only when the
data genuinely requires such a precision?

Peter. 


William Pence wrote:
> 
> I basically have an open mind about the suggestion to support 64-bit
> integers in FITS files, but just wanted to make a couple comments:
> 
> - it would be a fairly trivial job to modify the FITS standard to
> specify the format for 64-bit integer images and binary table columns.
> Images would have BITPIX = 64, tables would have TFORM = 'K' (or
> whatever), and the binary data itself would be written as
> twos-complement signed binary integers containing 8 bytes.  Not much
> more needs to be said.  There is no restriction on the value of integer
> keywords, so they already support 64-bit integers (but most
> readers/writers only support 32-bit integers).
> 
> - supporting the reading or writing of FITS files containing 64-bit
> integer data on 32-bit platforms would likely require a lot of work.  If
> the hardware/compiler doesn't support reading and writing 64-bit
> integers then interface software like CFITSIO would have to have
> software emulation routines to do datatype conversion between 32-bit int
> <-> 64-bit int, 64-bit float <-> 64-bit int, etc. and also trap any
> overflow conditions.  Presumably there already exist routines to do all
> this, written in C, that could be used in CFITSIO.  None the less,
> adding support for 64-bit integers in CFITSIO, not to mention all the
> other existing FITS readers and writers, would be a big job, and would
> make the interface software even more complex than it already is.
> 
> - There would still remain the problem that it is not possible in
> principle to fully represent 64-bit integers on a 32-bit machines
> without possible overflow (when converting to 32-bit integers) or loss
> of precision (when converting to double precision floating point).  Thus
> one could quite easily write FITS files on 64-bit machines that could
> not be read on 32-bit machines.  This would defeat one of the main
> purposes of FITS to provide a machine-independent data interchange
> format.
> 
> ____________________________________________________________________
> 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)