|
|
|
Thread Tools | Display Modes |
#2
|
|||
|
|||
Mark Calabretta writes:
I support the proposal, though with one reservation: how will cfitsio (or your favourite FITS reader) load a BITPIX=64 image onto a 32-bit computer? Are we assuming the availability of "long long int" in C (as is gcc), INTEGER*8 (or whatever it is) in FORTRAN, and similarly in other languages? Will coercing these values to double precision be considered acceptable if 64-bit integers are not available? The BITPIX=64 part of the proposal is indeed a bit less obvious than the rest. It seems a logical thing to do for consistency, but offhand I cannot think of an application that would need 64-bit integers in an image (as opposed to the very clear need for 64-bit time ticks and pointers in tables). Is there anything around that will make use of that capability in the foreseeable future? And if not, should we nonetheless include it on the basis of low implementation cost (specially three years down the road, when all our laptops will be 64-bit ;-)), or not? |
#3
|
|||
|
|||
Forwarded message:
From Wed May 4 03:38:50 2005 From: Thierry Forveille MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 3 May 2005 15:30:15 -1000 (HST) To: Mark Calabretta Subject: [fitsbits] 64-bit integers In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 7, autolearn=not spam, BAYES_00 -4.90) Cc: , William Pence X-BeenThe X-Mailman-Version: 2.1.5 Precedence: list List-Id: International FITS discussion list fitsbits.listmgr.cv.nrao.edu List-Unsubscribe: http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits, ?subject=unsubscribe List-Archive: http://listmgr.cv.nrao.edu/pipermail/fitsbits List-Post: List-Help: ?subject=help List-Subscribe: http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits, ?subject=subscribe Sender: Errors-To: X-MailScanner-Information: Please contact for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 7, BAYES_00 -4.90) X-LeidenObservatory-MailScanner-Information: Processed through MailScanner at Leiden Observatory X-LeidenObservatory-MailScanner: Virusscan: Found to be clean X-MailScanner-From: Mark Calabretta writes: I support the proposal, though with one reservation: how will cfitsio (or your favourite FITS reader) load a BITPIX=64 image onto a 32-bit computer? Are we assuming the availability of "long long int" in C (as is gcc), INTEGER*8 (or whatever it is) in FORTRAN, and similarly in other languages? Will coercing these values to double precision be considered acceptable if 64-bit integers are not available? I support the proposal if anyone has an application to which 64-bit integers are relevant. Whether any particular computer or software application can handle 64-bit integers (in "native" form) is mostly irrelvant, since FITS is a transport medium, not a local internal format. In the early FITS days a somewhat similar situation occured with floating point numbers. Each machine had its own internal representation, but FITS supports only IEEE floating point, and each local installation had to decide what to do with it. In the current case you have to choose a local representation (e.g. 2 32-bit integers) and a local arithmetic implementation (e.g. a C-function or C++ overloaded operator) to add/multiply/compare... the local representation. Walter |
#4
|
|||
|
|||
It appears that most software environments (e.g., C/C++, Fortran, Java, IDL,
Tcl/tk, ...) now support 64-bit integers. Can anyone cite a case where this is not true? Note that C compilers can define this type differently, so it might be declared as 'long long' (on many 32-bit systems), 'long' (on many newer 64-bit computers), or '__int64' (on early versions of Microsoft Visual C++). In the case of CFITSIO, the new 3.0 beta release now requires that the C compiler have a 64-bit integer data type. This version has only been out for about a month, but so far no one has reported any problems compiling it. Here are a couple other secondary issues about 64-bit integer support that I'm aware of: - some languages only support signed 64-bit integers, and do not natively support unsigned 64-bit integers (e.g., Fortran and Java, I think). In these systems integer values greater than 2**63 would appear as negative values. Software applications that must support the full range of unsigned 64-bit integers could probably be written to test for any negative values, and then reinterpret the value as the correct unsigned value. - many libraries written in C (including CFITSIO) rely on the 'cfortran.h' macros, written by Burkhard Burow, to provide the machine-independent Fortran interface to the library routines. cfortran.h does not support 64-bit integers, so, for example, Fortran programmers currently cannot use CFITSIO to directly read or write 64-bit integers in FITS file. It is still possible to read/write the 64-bit integer FITS values cast as double precision floating point variables in the Fortran program, but this is not a generally acceptable alternative. The eventual solution to this problem will be to add support for the 64-bit integer data type to cfortran.h, however these macros are VERY complicated, so it will require someone with a lot of expertise in C and Fortran to do this. Bill Pence Mark Calabretta wrote: Given the past controversies about adding 64-bit integer support to FITS, it is somewhat remarkable that there has been so little discussion of this now. I support the proposal, though with one reservation: how will cfitsio (or your favourite FITS reader) load a BITPIX=64 image onto a 32-bit computer? Are we assuming the availability of "long long int" in C (as is gcc), INTEGER*8 (or whatever it is) in FORTRAN, and similarly in other languages? Will coercing these values to double precision be considered acceptable if 64-bit integers are not available? -- __________________________________________________ __________________ Dr. William Pence NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) |
#5
|
|||
|
|||
Walter Jaffe wrote:
I support the proposal if anyone has an application to which 64-bit integers are relevant. Whether any particular computer or software application can handle 64-bit integers (in "native" form) is mostly irrelvant, since FITS is a transport medium, not a local internal format. The data analysis software used by the high energy astrophysics community generally uses FITS as the internal analysis format as well as the archive format. Many of the analysis packages used by the UV/optical/IR research community also use FITS as the primary internal format. The radio research community on the otherhand still seems to largely follow the model of only using FITS as an archive or transport format. Bill -- __________________________________________________ __________________ Dr. William Pence NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) |
#6
|
|||
|
|||
In testing for aips implementation I discovered that the HP Fortran
compilers will not accept INTEGER*8 but the the IBM (Mac), GNU (Linux) and SUN (Solaris Ultra) all accept that statement and do the right things. Eric Greisen |
#7
|
|||
|
|||
On Wed, 4 May 2005, Eric Greisen wrote:
In testing for aips implementation I discovered that the HP Fortran compilers will not accept INTEGER*8 but the the IBM (Mac), GNU (Linux) and SUN (Solaris Ultra) all accept that statement and do the right things. Just in case everybody doesn't know this, can I point out that INTEGER*8 isn't (and has never been) valid Fortran, just a fairly common extension to the various standards. So it may be that HP Fortran really doesn't support 64-bit integers, but a better test would be to try something like integer(kind=selected_int_kind(16)) :: variable and see if that compiles [the '16' is the number of decimal digits to be supported]. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 |
#8
|
|||
|
|||
I think it's not the role of the FITS standard to specify what to do on a computer which has not the native 64-bit implementation. And even if it is hard to imagine an image requiring 64-bit dynamics, it would look strange (in my opinion) to accept 64-bit arithmetics in tables but not in the main FITS components. On Mon 2005/05/02 16:14:57 -0400, William Pence wrote in a message to: Given the past controversies about adding 64-bit integer support to FITS, it is somewhat remarkable that there has been so little discussion of this now. I support the proposal, though with one reservation: how will cfitsio (or your favourite FITS reader) load a BITPIX=64 image onto a 32-bit computer? Are we assuming the availability of "long long int" in C (as is gcc), INTEGER*8 (or whatever it is) in FORTRAN, and similarly in other languages? Will coercing these values to double precision be considered acceptable if 64-bit integers are not available? Mark Calabretta ATNF ================================================== ============================== Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: (France) Fax: +33-(0)390 24 24 32 ================================================== ============================== |
#9
|
|||
|
|||
Eric Greisen wrote:
In testing for aips implementation I discovered that the HP Fortran compilers will not accept INTEGER*8 but the the IBM (Mac), GNU (Linux) and SUN (Solaris Ultra) all accept that statement and do the right things. The current HP Fortran Programmers Reference Guide (http://docs.hp.com/en/B3908-90006/ch03s01.html) claims to support INTEGER(8). |
#10
|
|||
|
|||
Hi Clive,
at least for HP there is no problem he http://docs.hp.com/en/5966-9887/ch02s03.html and for other systems (e.g. Cray T90) the 64bit integers are even default, i.e. if you define a variable as integer without any kind parameter it will be a 64bit integer (see http://docs.cray.com/books/007-3692-...-007-3692-003/ fvbalchri.html) Actually the Fortran standard does allow, but does not require any 'kind' parameter, thus even INTEGER*2 or INTEGER*4 are not 'valid' Fortran to follow your wording. Andreas On 04.05.2005, at 19:38, Clive Page wrote: On Wed, 4 May 2005, Eric Greisen wrote: In testing for aips implementation I discovered that the HP Fortran compilers will not accept INTEGER*8 but the the IBM (Mac), GNU (Linux) and SUN (Solaris Ultra) all accept that statement and do the right things. Just in case everybody doesn't know this, can I point out that INTEGER*8 isn't (and has never been) valid Fortran, just a fairly common extension to the various standards. So it may be that HP Fortran really doesn't support 64-bit integers, but a better test would be to try something like integer(kind=selected_int_kind(16)) :: variable and see if that compiles [the '16' is the number of decimal digits to be supported]. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 _______________________________________________ fitsbits mailing list http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FITS long integer support (was [fitsbits] ADASS FITS BoF onSunday) | Eric Greisen | FITS | 10 | October 26th 04 08:14 AM |
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 |
Dobsonian question | bkiff | Amateur Astronomy | 37 | November 25th 03 11:39 PM |
[fitsbits] BLANK keyword misinterpretation | Steve Allen | FITS | 4 | November 21st 03 05:42 PM |