Comments on NOST 100-1.2

[Lucio Chiappetti]

On Wed, 8 Jul 1998, JENNINGS Don wrote:

>   2. 64-bit processors are now common. This implies that the
> use of the "long int" data type in programs will be more

  How common ? AFAIK we have DEC Alphas (will they survive Compaq ?) and
  Sun UltraSparc (but the OS does NOT use 64-bit features, or at least so
  they told me when I inquired about migration, thinking of having similar
  problems as the Ultrix-->Digital Unix transition)

  Is INTEGER*8 in Fortran now standard ? or just supported by a few vendors ?
  (and by the way, why should one need it ?)

>   3. 64-bit operating systems are now common. This implies
> that there are quantities generated that cannot be expressed
> in a 32-bit integer any longer; e.g., memory addresses, file
> sizes.

  See above for comment on how common they are. 
  The quantity you mention are not relevant talking of the CONTENT of DATA
  files.
  And I doubt they are of practical use in common conditions (I see that
  peoples in banks and similar tend to have large databases, but I ever
  doubt to need a > 2GB file  ... or to have > 2GB physical memory ... and
  since I do not have that, why should I need 64-bit addresses ? In fact
  on Alpha I compile EVERYTHING with the -taso option : Truncated Address
  Space Option, so that addresses fit into 32 bits and I have portable
  code)

>   6. The only reasons that I have heard agaist 64-bit
> integer support essentially condense into "we can live
> without it".

  I still believe we can.
  Unless you want to solve the problem of the inventor of the game of
  chess (if you put a grain of rice on the first square of the chessboard,
  two on the second, four on the third ...) why should one need to COUNT
  such large numbers with ABSOLUTE precision ?  REAL*8 should be enough.

  40- or 48-bit s/c clocks are the only things which comes to my mind,
  but s/c clocks are such a pain in the neck anyhow (also because they are
  unsigned :-( ). And in practice one never has so long elapsed periods or so
  fast timing that one cannot either round to "Unix time seconds" or MJD, or
  use full resolution in a limited interval, or convert to REAL*8 elapsed
  seconds.

I'm a supporter of Ockham's razor :

"file formats, data structures, data types non sunt multiplicanda praeter
necessitatem" 



>      II. Unsigned Integer Convention
>

Oh Yet Another Data Type !
But fortunately as you say ...

> Fortuantely, there is a way to store
> unsigned integers in the current FITS standard using the
> BZERO (for primary arrays and IMAGEs) and TZEROn (for
> BINTABLEs) keywords. 

Thus I support the specific inclusion in the documentation of the way how to
use them.

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)      
Member of the Ockhamist's Club, together with 
William of Ockham, Guglielmo da Roveredo, Wilhelm von Eichdorf
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------