FITS long integer support (was Re: [fitsbits] ADASS FITS BoF on Sunday)

[LC's No-Spam Newsreading account]

I enter briefly in the 64-bit integer issue with some sparse
considerations.

On Fri, 22 Oct 2004, Eric Greisen wrote:

> All too often I have seen people get excited about "new" things and
> use them for the fun of it.  [...]

I agree, and I agree also with the implicit suggestion that such
"enthusiastic" approach should be avoided.

>                       [...]  FITS may be very useful as an internal
> and archival format but it got those uses by adhering to the
> requirements for transporting data.  The transport in internal and
> archive uses is across local platforms and across time rather than
> between observatories, but it is nonetheless transport.

I agree that archiving is a form of transport.

On Thu, 21 Oct 2004, Steve Allen wrote:

>     Be liberal in what you accept, and conservative in what you send.

I endorse this too

> I personally expect to be making routine use of 64-bit processors
> within the next year.  Taking into account the time and effort

I've on my desktop since ages what I believe was the first 64-bit
processor (an *OLD* DEC - yes, at the time still Digital Equipment
Corporation - Alpha) with full 64-bit support at OS level (I believe the
64-bit mode in Solaris is not a full support), and I've never had the
need to use files longer than 2 GB, or INTEGER*8 variables (not to
mention memory addressing : I've actually always used my Fortran
compilers in -taso "Truncated Address Space" mode !).

We are currently in the process of replacing all our Suns and Alphas
with Intel+Linux machines, and the 64-bit issue has never been
considered an hot issue (actually it has never been considered at all,
may be we overlooked it ...).

Concerning usage of 64-bit integers therefore I hardly see the need for
them. While the 16-bit to 32-bit increase was a real need (a 16-bit
COUNTER is really poor), I do not see in general needs for quantities
(excluding addresses !)  which need the precision of a 64-bit integer.

Using 64-bit integers as default integers seems to me a waste.

And for what addresses are concerned, I tend to consider that dealing
with small chunks is more practical when "transport" (including
archiving and network access) is concerned.

The only "real" issue which has been mentioned is possibly that of time
counters (e.g. spacecraft clocks, usually 48-bit). It has always been a
pain in the neck to deal with them, projecting them on a limited
interval with high resolution, or a longer interval with poor
resolution, or casting them into a double precision value offset from a
time start coded in a keyword (some of the solutions I used). But may be
at that level we'd need a WCS paper on time representation.


On Fri, 22 Oct 2004, William Pence wrote:

> this may boil down to a language divide: C/C++, Java, Fortran-90, and
> probably most other new languages naturally support long integers, but
> Fortran-77 doesn't.

Despite the fact that I'm still an extensive user of f77 software, and
have not done any extensive developments in f90-95, I will break here my
conservativeness, and say that we should not be worried by the above.
Any NEW development should take into consideration only f90 and later.

PS
Apologies for a short message sent by mistake while composing this.

Lucio Chiappetti - IASF Milano

-- 
----------------------------------------------------------------------
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.