🚀 go-pugleaf

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.
> 
> One solution we have devised is to save the 7th byte of VAX real*8 values, 
> where the loss of precision occurs, and add them to a column of the binary
> table where the real*8 values are being stored. The following is a suggested
> list of rules for the extra column:
> 
>    It would always be the last column of the table.
> 
>    Each column entry would contain the 7th byte of all real*8 values
>    occurring in a given row. Thus, if a table row contained 5 real*8
>    values, then the extra column's TFORM code would be 8B, if the

I think you mean 5B, not 8B  (?)

>    row contained any real*8 variable length array entries then the
>    extra column's TFORM code would be PB(XXXX).
> 
> FITS readers residing on non-VAX architectures would be able to ignore the
> extra column, while VAX FITS readers could completely reconstruct the original
> real*8 value by reading the extra column's values.

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.  So I think
you have 2 choices.

1.  If this added precision in the VAX value is really significant, then you 
need to find a portable way of including it in the FITS file.  One way might be
to express the double precision value as 2 columns:  one containing the integer
part, and the other containing the fractional part of the value.

2.  If the added precision in the VAX value is not really significant (the VAX
G_floating datatype has effectively 4 more bits of precision than an IEEE R*8 value)
then one should not worry about it, and one should accept the fact that the
FITS file cannot preserve every last bit of information on every type of machine.

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.

-Bill Pence