A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] 64-bit integers



 
 
Thread Tools Display Modes
  #2  
Old May 4th 05, 02:30 AM
Thierry Forveille
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 09:30 AM
Walter Jaffe
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 05:12 PM
William Pence
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 05:29 PM
William Pence
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 05:31 PM
Eric Greisen
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 06:38 PM
Clive Page
external usenet poster
 
Posts: n/a
Default

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
  #9  
Old May 4th 05, 07:05 PM
William Pence
external usenet poster
 
Posts: n/a
Default

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  
Old May 4th 05, 08:24 PM
Andreas Wicenec
external usenet poster
 
Posts: n/a
Default

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 11:04 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.