Thread View: sci.astro.fits
2 messages
2 total messages
Started by Don Jennings
Thu, 17 Dec 1992 13:54
VAX R*8 to FITS/IEEE R*8 conversion problem
Author: Don Jennings
Date: Thu, 17 Dec 1992 13:54
Date: Thu, 17 Dec 1992 13:54
28 lines
2051 bytes
2051 bytes
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
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.
Has anyone out there had this problem? Does anyone out there have a
different solution? If so, then I would like to hear from you. Please
send/post any general comments on the above scheme you might have as well.
Don Jennings, COSSC/GSFC
Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Author: William Thompson, code 682.1, x2...
Date: Thu, 17 Dec 1992 20:04
Date: Thu, 17 Dec 1992 20:04
42 lines
2926 bytes
2926 bytes
In article <JENNINGS.92Dec17085450@antwrp.antwrp.gsfc.nasa.gov>, jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings) writes... >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. This statement alone raises warning flags in my mind. I'm firmly of the opinion that the structure of binary tables should not in any way depend on the order in which the columns appear. If you're going to do something like this, you should indicate the column with an appropriate label (TTYPE). > > 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 > 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. > >Has anyone out there had this problem? Does anyone out there have a >different solution? If so, then I would like to hear from you. Please >send/post any general comments on the above scheme you might have as well. > > Don Jennings, COSSC/GSFC If that last byte is important, than it will be important regardless of what computer you're analyzing the data on. If so, then a better, more machine-independent way of transferring the full significance of the data has to be devised. If it isn't important, then one shouldn't worry about it. Bill Thompson
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