🚀 go-pugleaf

On Thu, 17 Dec 92 11:30:58 EST William Pence said:
>Don Jennings wrote:
>
>> My organization often needs to convert data that is native to the VAX
>> architecture into a FITS format. Since the VAX real*8 bit pattern is
>different
>> from the FITS/IEEE real*8 bit pattern, it is not possible to completely
>> encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision
>> occurs when transforming a VAX real*8 into an IEEE real*8.
>
>My reaction to this is that it is not very useful to put information in a FITS
> file
>that only a particular machine will be able to interpret.  One of the main
> purposes of
>FITS is to make the information in the file portable to any machine.

 I would tend to agree with Bill on this.


>
>1.  If this added precision in the VAX value is really significant, ....
>2.  If the added precision in the VAX value is not really significant ...
>

  I had recently the converse concern of this, that is not about the
  added precision in the Vax representation, but the fact that the IEEE
  representation for REAL*8 allows a wider range of exponents, larger than
  the 1.E-38 to 1.E38 allowed by usual (D_FLOAT) on Vax
  (as clearly stated by Bill here below)

>As an aside, I'm sure you are aware that the VAX has 2 different R*8 data
>representations.  The default D_floating representation which you are probably
> using
>reserves 8 bits for the exponent and 55 bits for the mantissa.  The G_floating
>representation on the otherhand is similar to the IEEE R*8  representation:
>both
>have 11 bits for the exponent and 52 bits for the mantissa.  The G_floating
>and IEEE values are still not identical though because the VAX interprets the
>exponent and mantissa numbers as normalized, ("hidden bit normalization") which
>effectively gives you another bit of precision compared to the IEEE value.
>If you were to use G_floating on the VAX, you probably would not notice the
>loss of precision in converting the data back and forth from FITS.
>

  I recently was engaged in setting up something able to exchange files
  between Vaxes (2-complement byteswapped integers, Vax format REAL*4 and
  REAL*8 D_FLOATs), Suns (2-complement integers, IEEE REAL*4 and REAL*8) and
  DECstations (2-complement byteswapped integers, byteswapped IEEE REAL*4 and
  *8). The idea was to copy the files and convert them in place without
  passing through an intermediate FITS file.

  The idea is to use some simple routines, and to change the file in place
  on the destination machine (therefore only a conversion foreign-->local
  is needed on each operating system)

  The byteswap can be easily handled in Fortran in a portable way. For the
  conversion from IEEE to Vax format on VMSI use some assembler routines kindly
  provided by Bill in his FITSIO packages (on copyright from the IRAF team).
  The R*4 Vax to IEEE can be easily handled in Fortran on Unix, due to the
  fact that all what is needed is to shuffle bytes and adjust the exponent
  bias.  I have for the moment suspended work on the R*8 Vax to IEEE
  conversion because I need to clear my mind.

  The conversion from G_FLOAT would be analogous to the R*4 one, but the
  one for D_FLOAT (the reverse of the ieeed routine in the IRAF VMS assembler
  routine) is not obviously done in Fortran.
  What I am uncertain of, is whether I should continue using D_FLOAT on Vax
  or move to G_FLOAT.

  I actually use quite a limited amount of REAL*8 values, and I was always
  happy with applying some scale factors when exceeding the exponent range
  (1.OE38 for both R*4 and D_FLOAT R*8). From the quoted assembler routine
  I derive that IRAF does the same.

  I would appreciate to know other people's opinion on the matter
  whether G_FLOAT should be recommended on VMS for IEEE compatibility,
  or not.

-----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager
Internet: LUCIO@IFCTR.MI.CNR.IT            |           FORTUNAE SUAE
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |
Bitnet:   EXOSAT@IMISIAM                   |
-----------------------------------------------------------------------------