Comments on NOST 100-1.2

[JENNINGS Don]

Hello all,

I have briefly reviewed the new draft FITS standard NOST
100-1.2 and have the following three comments. Since I do
not subscribe to the FITSBITS exploder or normally read
sci.astro.fits, please forgive me if my comments have
already been discussed. I ask that the NOST Technical Panel
consider my comments for inclusion into the new Standards
document.


      I. Support for 64-bit integers

I believe that this is the right time to add the 64-bit
integer data type to FITS. Reasons:

  1. Other data formats support 64 bit integers. The lack of
64-bit integers in FITS is a significant obstacle when
importing non-FITS data into FITS.

  2. 64-bit processors are now common. This implies that the
use of the "long int" data type in programs will be more
frequent. FITS must be able to store these integer values if
it is to be a usable format.

  3. 64-bit operating systems are now common. This implies
that there are quantities generated that cannot be expressed
in a 32-bit integer any longer; e.g., memory addresses, file
sizes.

  4. It is extreamly simple to do. Primary Arrays and IMAGE
extensions will accept BITPIX = 64, and BINTABLES will
accept TFORM = 'rKa'. 

  5. 64-bit integer values are at least as useful and worthy
of support as the complex data types. I personally have
never needed to store complex numbers in a FITS file, nor
known anyone with the need, but have needed 64-bit integer
support several times (.e.g., onboard spacecraft clock
times).

  6. The only reasons that I have heard agaist 64-bit
integer support essentially condense into "we can live
without it". But I claim the time has come where we cannot
live without it. I suspect that the programmers that limited
the expression of the year to two digits had a similiar "we
can live without it" argument in the 60's and 70's.
  
If the NOST Technical Panel decides not to include 64-bit
integer support in the new version of the standard, then I
ask that they at least provide their reasons for not doing
so in the new Standards document. This way history can make
them accountable for their decision.


     II. Unsigned Integer Convention

The desire for support of unsigned integers has, I believe,
been expressed before. Fortuantely, there is a way to store
unsigned integers in the current FITS standard using the
BZERO (for primary arrays and IMAGEs) and TZEROn (for
BINTABLEs) keywords. See the CFITSIO Users manual for more
details.

I request that this convention be described in one of the
appendicies of the new Standard. It could be extreamly
useful for the newer generation of FITS readers and writers
to support this convention. Note that: (1) it is already
supported by software (CFITSIO), and (2) it is already in
use within the community.


    III. Alternate Substring Array convention B.3

The array substring convention provided in appendix B3,
where substrings may be expressed as 'rA:SSTRw/nnn', should
also list the alternate convention of 'rAw' where:

r = the total length of the ASCII character field
w = the width of each substring in the character field

Note that this convention: (1) is already suported by
software (CFITSIO), (2) is already in use within the
community, and (3) is much more likely in general to be used
over the 'rA:SSTRw/nnn' convention due to its simplicity.


Thank you,

Don Jennings

-- 

                                                  
------------------------------------------------------------------
If you understand what you're doing then you're not learning 
anything

Don JENNINGS                     
INTEGRAL Science Data Centre     E-mail:
Don.Jennings at obs.unige.ch 
16, Chemin d'Ecogia              Phone:  +41 22 950-91-23
CH-1290 Versoix                  Fax:    +41 22 950-91-33

------------------------------------------------------------------