[fitsbits] FITS 'P' descriptors: signed or unsigned?

LC's No-Spam Newsreading account nospam at mi.iasf.cnr.it
Thu Jun 16 10:17:49 EDT 2005


On Wed, 15 Jun 2005, William Pence wrote:

> At issue is whether to reverse the recent decision to define the 'P'
> variable-length array descriptors in FITS binary tables to be a pair of
> 'signed 32-bit integers', and make them 'unsigned 32-bit integers' instead.

> The practical consequence of this change is that it will double the allowed
> heap size from about 2.1 GB to about 4.2 GB.

the same result (going beyond, actually WELL beyond, 2 GB) could be 
achieved with the new Q type pointers. For the Q type pointers being 
signed or unsigned really does not matter (a factor of 2 on "nearly 
infinity" :-) ).

> The main argument for keeping the descriptors as signed integers is that FITS
> has never supported unsigned integers as a raw data type (although it does

That is a valid "elegance" argument, I would say as valid as the fact 
that data and pointers are two different things (the two cancel out 
reciprocally).

> How do others feel about this issue?  Is there a clear consensus one way or
> the other?  Should the FITS committees be explicitly asked to vote on a
> preference?

I suggest the issue is voted together with the Q descriptors, since it 
requires a change to the recently approved standard, and there is no 
sense in having P signed and Q unsigned.

So either we vote 

  (A) to have Q signed (requiring no change to the April vote), or we vote 
  (B) to introduce Q unsigned, and at the same time make P unsigned.

I'm not sure of the best way. If the matter is sorted out by preliminary 
discussion, than a "traditional" vote is called on either proposal (A) 
or proposal (B). Do the formal voting rules allow to vote on a 
non-binary alternative ( YES A, YES B or NO instead of YES NO) ?


My concerns with the unsigned issue are two :

 - one is the Once FITS Always FITS ... but this is probably weak,
   all files produced before April were "not official" so there won't
   be many produced afterwards. And anyhow all the "signed" one, if
   not negative (as they should not be) remain legal.

   However some s/w has to be changed (if there is any which is affected
   they should speak now or never !)

 - the other one is that unsigned may not be supported by all 
   programming languages (I'm specifically thinking of Fortran), which
   somehow imbeds a language preference in FITS. It is however true
   than one can call a library routine supporting unsigned in another
   language. And this will apply only to case of "large heaps" ...
   ... after all a program written for a specific purpose can 
   legitimately detect a particular FITS feature and decide not to 
   support it (if not required in specific context). Such a program
   could transparently support descriptors until the n-1 bit limit,
   and signal "unsupported" if the descriptor "goes negative" for it.

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.



More information about the fitsbits mailing list