[fitsbits] 64-bit integer comments

[LC's No-Spam Newsreading account]

I collect together a few miscellaneous answers :
 
On Tue, 10 May 2005, Harro Verkouter wrote:

> This is where I'd like to mention that radio astronomy IS using FITS 
> for the T it stands for: transport. We're also already producing 
> datasets of 20GB up to 200GB. Currently, we have to break these up 
> into pieces not larger than 2GB, which is not difficult but ...

I suppose however that the breaking into pieces is due either to 
filesystem size limitation on some old OS's or to the need of using 
relatively small files for network exchange. Bill says something like 
that in a later message.

There is nothing in the FITS standard which limits the file size. The P 
descriptor (as opposed to the proposed Q descriptor) limits the size of 
the heap area *only*. Is this correct ?

----------------------------------------------------------------------
On Tue, 10 May 2005, Thierry Forveille wrote:

> Note that with BZERO and BVAL, BITPIX=64 need not be a count image. 
 
but if it's not a "count" (or other discrete, quantized quantity) who 
will use nowadays an integer with BZERO and BVAL and not use instead a 
float or double ?

> additional phase space does not bring up any more use case to my mind,
> though ;-)
 
That's the point !    

----------------------------------------------------------------------
On Wed, 11 May 2005, William Pence wrote:

> Also, FITS images can be used to store n-dimensional arrays of any 
> type of quantity; they are not just used for 2-D spatial 'counts' 
> images.  It is not difficult to dream up only slightly contrived cases 
                                           !!!!!^^^^^^^^^^^^^^^^^^!!!!!! 
         
... slightly contrived which could possible be stored (more simply and 
naturally) as binary tables.

> 3)  On the practicality of using 64-bit floating point variables as a
> substitute for long integers:
 
> The main worry I have with this is that floating point computational 
> results may not be an exact integer.

this is true, but I really haven't encountered a single case in which I 
needed such exact accuracy over a really large dynamic range except for 
the classroom exercise of summing 2**i for i=0,63 with full precision on 
a 36-bit Univac :-)
        
----------------------------------------------------------------------
On Thu, 12 May 2005, Francois Ochsenbein wrote:

> I tend to prefer the original FITS definitions (published in 
> 1995A&AS..113..159C) which explicitely says "negative offsets are not 
> permitted" [...] There is no real need to introduce the unsigned 
> arithmetics -- but I feel important to clearly specify that "negative 
> offsets are not permitted".

agreed

----------------------------------------------------------------------
To summarize my view :

 - I see no case for BITPIX=64

 - I see some limited, quite specific cases for TFORM K, and I'm ready
   to accept it with an appropriate caveat (otherwise said, I do not
   think as obvious to make a jump for default integer range from 32 to
   64 while it was obvious to make the one from 16 to 32, or would be
   for float ... in fact a number of packages do internally floating
   point calculation in double precision)

 - I do not see a particular need for Q descriptors (I'm thinking that
   files with a large heap are unpractical) but since there is no other
   size limitation I could accept it, but the signed/unsigned issue
   should be dealt with uniformly with the rest, i.e. I favour signed 
   non negative.

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.