[fitsbits] 64-bit integer comments

[Preben Grosbol]

On Wednesday 11 May 2005 21:43, William Pence wrote:
> Here are some comments on several aspects of the 64-bit integer discussion:
>
> 1) On the suggestion to only add support for 64-bit integers in binary
> tables, and not in primary arrays:

I still don't see a convincing argument for adding BITPIX=64.  That it
may be simple  to add it in interface libraries is not a reason for doing
it.  For image data, the problems start as soon as one does something
to the data (e.g. just a multiplication or division, not to think of applying
functions).  Both physically and technically I don't see the need.  Images
with pointers or identifiers are better treated in other ways.

It is clear that we are too close to the 31/32-bit limit for heap pointers.
The unsigned 32-bit gives too little to be interesting so the only
reasonable thing would be to consider 64-bit pointers.  As argued,
in practice we can do with signed 64-bit for a long time so to limit
the types we need to deal with I would prefer signed values.  Such
a proposal could be made separately as it does not interfere with
the other 64-bit issues.

For table columns, the time stamp argument is convincing.  Although
one could place images in such columns, it's complicated enough
that few would do it if there is not a real need.  Since one often would
take differences the added range of unsigned values may not be easy
to use.  Thus, signed 64-bit integers would be the reasonable choice.

Preben Grosbol