Thread View: sci.astro.fits
4 messages
4 total messages
Started by William Pence
Thu, 17 Dec 1992 16:30
Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Author: William Pence
Date: Thu, 17 Dec 1992 16:30
Date: Thu, 17 Dec 1992 16:30
55 lines
3427 bytes
3427 bytes
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
Re: VAX R*8 to FITS/IEEE R*8 conversion prob
Author: Chris Flatters
Date: Thu, 17 Dec 1992 18:09
Date: Thu, 17 Dec 1992 18:09
24 lines
1889 bytes
1889 bytes
In article AA05949@tetra.gsfc.nasa.gov, pence@tetra.gsfc.nasa.gov (William Pence) writes:
>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.
IEEE values are also normalized as long as they are greater than or equal
to 2 ** E_min, where E_min is the minimum exponent. An IEEE-754 double
has a precision of 53 base-2 digits (identical to VAX G-floating) as long
as E >= E_min (E_min = -1022). VAX G-floating and IEEE-754 doubles probably
differ in the bias of the exponent (this is the difference between normalized
IEEE singles and VAX F-floats).
Incidentally, if you think about it you will realize that the exponent can
not be normalized.
Chris Flatters
cflatter@nrao.edu
Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Author: Don Jennings
Date: Thu, 17 Dec 1992 19:41
Date: Thu, 17 Dec 1992 19:41
47 lines
3126 bytes
3126 bytes
In article <9212171630.AA05949@tetra.gsfc.nasa.gov> William Pence writes:
I think you mean 5B, not 8B (?)
Yes, I meant 5B not 8B; sorry for the dyslexia
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.
The precision is significant, in that we must be able to repoduce the original
data byte for byte. Breaking the VAX R*8 up into an IEEE R*8 + remainder would
still introduce roundoff error.
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 was aware of the D_floating and G_floating compiler options, but did not
know that much about them. Unfortunately, the data is produced using D_floating
and there is nothing we can do about it.
Thanks for your interest Bill. I'll think about what you had to say.
Don Jennings
Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Author: Robert S. Hill
Date: Thu, 17 Dec 1992 20:10
Date: Thu, 17 Dec 1992 20:10
28 lines
1973 bytes
1973 bytes
In article <JENNINGS.92Dec17144132@antwrp.antwrp.gsfc.nasa.gov>,
jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings) writes...
>In article <9212171630.AA05949@tetra.gsfc.nasa.gov> William Pence writes:
> 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.
>
>The precision is significant, in that we must be able to repoduce the original
>data byte for byte. Breaking the VAX R*8 up into an IEEE R*8 + remainder would
>still introduce roundoff error.
I just want to cast a vote that stuffing part of the VAX precision into
the IEEE format (with an auxiliary byte) seems like questionable style
to me. It would be much better to split the number up, as someone
suggested, into an exponent and mantissa, then store those as integers.
Extended precision formats you make up yourself from scratch, cleanly,
should be easier to deal with than ``IEEE-plus.''
Perhaps it would be better for user-friendliness to make the exponent
fix(log10(stuff)) instead of fix(log2(stuff) + offset)
with the corresponding change in the mantissa.
Robert S. Hill
bhill@stars.gsfc.nasa.gov
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads