🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Don Jennings Thu, 17 Dec 1992 13:54
VAX R*8 to FITS/IEEE R*8 conversion problem
#60
Author: Don Jennings
Date: Thu, 17 Dec 1992 13:54
28 lines
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
#67
Author: William Thompson, code 682.1, x2...
Date: Thu, 17 Dec 1992 20:04
42 lines
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