[fitsbits] 64-bit integers

[LC's No-Spam Newsreading account]

On Tue, 19 Apr 2005, William Pence wrote:

>         http://fits.gsfc.nasa.gov/fits_64bit.html

I finally found the time to read the above proposal. My arguments fall 
in the following categories :

1) system support of 64-bit integers
2) do we need image BITPIX=64
3) do we need BINTABLE columns TFORMn=mK
4) do we need 64-bit array descriptor pointers 1Qt
5) miscellaneous considerations

----------------------------------------------------------------------
1) system support of 64-bit integers
----------------------------------------------------------------------

I did a quick check and the situation is quite satisfactory, although 
the nomenclature is sometimes compiler dependent (for C as already 
stated, but also for Fortran where the INTEGER*n is a widespread 
extension and the KINDs are somewhat not standardized although e.g. the 
Intel compiler allows both INTEGER*8 and INTEGER(8) and 
INTEGER(KIND=8)), sometimes fixed (e.g. Java Long or IDL long64).

However the fact there is no uniform naming even in the same language 
should let us be at least a little suspicious.

Support to e.g. unsigned quantities is less uniform (e.g. possible but 
not native in java, not supported in Fortran), so I suggest we start 
dropping consideration of unsigned quantities.

For the rest the issue of system support is not a strong one (after all 
FITS was born with its 2880-byte recl when computers used 16, 32, 36, 60 
and 64 bits !) or which should concern us. A particular implementor can 
always decide not to support a particular feature, after all.

Said that, I'm a keen supporter of Ockham's razor (in the particular 
forms "data types non sunt multiplicanda praeter necessitatem" :-), and 
so we should consider if the request of 64-bit integers do not go 
"beyond necessity".

And we should do that CASE BY CASE (i.e. BITPIX, K TFORMn, Q 
descriptors) which in my opinion means also voting separately.

And also consider that the fact something exists (a data type or a 
feature is offered by a compiler) is not a reason why we MUST use or 
support it (I favour the opposite view, take a pick of a reduced subset 
of types or features which are really useful).

----------------------------------------------------------------------
2) do we need image BITPIX=64 ?
----------------------------------------------------------------------

An INTEGER*8 allows to store a number (in the 2**+/-63 range) with 19 
digits of precision. This should be compared with 10 digits for an 
INTEGER*4 (in the 2**-31 range) or 15 digits offered by a REAL*8 (in a 
broader range but not with complete precision).

Really I fail to see a case for which one'd *really* need such absolute 
precision for a count image.

Note that I'm not against use of BITPIX=-64 (double precision float) as 
I like using images to store matrices of arbitrary content (e.g. I can 
use a matrix to store a flux or a luminosity in CGS units).

Although I've seen too many lazy people wasting space using things like 
BITPIX=-64 to store photon images where one hardly has more than 100 
photons in a pixel, because some lazy programmers supported it as the 
default !

I can't imagine in 25 years a single case why I should need to count 
something in an image with INTEGER*8 precision (but for the case of 
solving the problem of the inventor of the chess game who asked a reward 
of one rice grain on the first square of the chessboard, two on the 
second, four on the third etc.  ... that was my favourite problem when 
we had to chose one in my 2nd year programming course ... solving 
sum(2**i) for i=0,63 at absolute precision on a 36-bit Univac machine 
:-) )

----------------------------------------------------------------------
3) do we need BINTABLE columns TFORMn=mK ?
----------------------------------------------------------------------

Here I think that similar arguments can be applied (are there many 
quantities which require 64-bit integer precision and cannot be 
accomodated by a REAL*8).

There is *possibly* a single case which comes to my mind, and that has 
already been mentioned (spacecraft clock time in telemetry, which is 
often stored as a 48-bit counter, or similar, or portion thereof).

Although probably I'd advocate more a thing like support for "abstract" 
standard types (e.g. a definition of a data type for "angles", which 
could be just a REAL*8 in degrees or radians, of one for "time" which 
could be just ... what ?) for SPECIFIC cases.

----------------------------------------------------------------------
4) do we need 64-bit array descriptor pointers 1Qt
----------------------------------------------------------------------

Here again I'm quite perplexed. A 64-bit pointer seems something 
designed to address positions in large datasets (possibly too large to 
be practically "transported" using FITS files ... after all T is for 
transport).

Also I noticed that 8.3.5 originally described array descriptors as 
"integers".

In the recent (IAUFWG approved) change it has been added a specification 
of "signed integers".

Now the proposed new change to support Q pointers reverses this wording 
and says "unsigned integers".

I would like to see a motivation of this reversal.

Also noting that unsigned quantities are otherwise only indirectly 
supported in FITS for all (old or new) integer quantities.

----------------------------------------------------------------------
5) miscellaneous considerations
----------------------------------------------------------------------

I wonder if phrases like "discouragement" and/or "negative 
recommendations" could be included in a standard document.

Otherwise said, I could support TFORMn=mK if it were clearly stated that 
it can be used ONLY in cases of REAL need.


The other thing is that I'd like to hear opinions (specially from the 
pulsar and fast timing communities) about issues related to time 
representation.

I've done some timing analysis myself, but not really fast timing, and 
in such cases I always managed to do things like : reading in Fortran a 
portion of spacecraft clock into an I*4, cast it into a REAL*8 using a 
C-wrapper (around udouble), scaling it by a 2**LSB resolution, 
adding/subtracting an offset and working with a REAL*8 quantity in 
seconds or milliseconds elapsed from a fixed time (usually 0 UT of the 
day when the observation began)


Lucio Chiappetti

-- 
----------------------------------------------------------------------
nospam at mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.