|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Preben Grosbol wrote:
On Thursday 16 June 2005 00:21, 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. I'm sorry but we cannot 'reverse the recent decision'. That would violate the section 9 of the FITS Standard 'Restrictions on Changes' With respect, changing the descriptors from 'signed' to 'unsigned' will not violate section 9 (which states "Any structure that is a valid FITS structure shall remain a valid FITS structure at all future times".) Any existing FITS file that contains positive signed integer heap descriptors (i.e., using only 31 bits) will continue to be a valid FITS file if the recent decision is reversed to define the pointers as unsigned integers (allowing full use of all 32 bits). In fact, it was the previous decision (to make the descriptors 'signed integers') that violated Section 9. Up until April 2005 it was legal to make FITS files with descriptor values greater than 2GB, but now they are invalid. Even though we made a deliberate decision to overlook the Section 9 requirement in that case (on the grounds that we did not know of any existing FITS files that had heaps larger than 2GB), it could be argued that the previous decision was 'unconstitutional', and therefore we must restore the less restrictive requirement that the descriptors be interpreted as unsigned integers. My own view on whether the 'P' pointers should be signed or unsigned integers is mainly driven by what what would be most useful for the FITS user community. Currently CFITSIO (and probably other FITS libraries as well) supports binary tables with heaps up to 4.2 GB in size. Why should we imposing an artificial restriction that only allows heaps that are 1/2 as large? In addition, I can see almost no software development cost to supporting these larger heaps. Any FITS file that makes use of this extended pointer range will necessarily be greater than 2GB in size (which in itself is perfectly legal since there has never been any restriction on the size of a FITS file). Any software that accesses these Large files must necessarily be using 64-bit addressing (at least on most computer platforms) to perform seeks and offsets in the file. Since the software is already handling 64-bit addressing, there should be no difficulty in supporting the full range of heap addresses allowed by the unsigned 32-bit descriptor. In any case, it is only the small number of FITS interface libraries that need to be modified to support the unsigned pointers. This should be completely transparent to any software that calls the FITS library to read and write the arrays in the heap, so existing applications programs should not need to be modified to support the larger heap size. Bill Pence -- __________________________________________________ __________________ Dr. William Pence NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FITS long integer support (was [fitsbits] ADASS FITS BoFon Sunday) | William Pence | FITS | 6 | October 22nd 04 08:23 PM |
[fitsbits] FITS long integer support | Steve Allen | FITS | 0 | October 21st 04 06:22 PM |
[fitsbits] Start of the FITS MIME type Public Comment Period | William Pence | FITS | 8 | June 17th 04 06:08 AM |
[fitsbits] Happy Birthday, FITS! | Don Wells | FITS | 0 | March 28th 04 01:58 PM |
Reading floating point FITS files | John Green | FITS | 34 | November 29th 03 01:31 AM |