[Issues] floating point format again...

[John P. McFarland]

Hi Hans,

This seems to be a problem with the interpretation of the FITS and IEEE 
floating point standards in the header module.

I created a header in both eclipse and pyfits, added your value to it and 
came up with the same result directly, after saving the files, and after 
reloading the headers from files.  Neither eclipse nor pyfits has any 
problem with a missing decimal point in the floating point number stored in 
the header.

Eclipse does have some FITS standard checking built-in, probably not much, 
but it is there.  Pyfits, on the other hand, has much better FITS standard 
checking (exercised by output_verify), yet they both give the same 
apparently incorrect result as above.  No matter how I add your value to a 
header, it is always stored without the decimal.

I looked into the pyfits code to see why, and found that the value is 
printed to the card as:

awe> print '%.16G' % -0.00000007
-7E-08

Modifying the pyfits code to properly include the decimal:

awe> print '%#.16G' % -0.00000007
-7.000000000000000E-08

will fix it.  I expect this can be done and we can implement a pyfits-based 
header into Astro-WISE, but it will take some time (the module is already 
written, but it will need to be integrated and tested).

I don't know if there is a quicker work-around, but it will not be able to 
start on it anytime soon unless it is absolutely necessary.

Cheers,


-=John


On Tue, 17 Jul 2007, Hans Vaith wrote:

> Dear All,
>
> this is a followup to the floating point format issue. It turns out that the
> LBCBLUE MEF FITS files actually store the CDi_j values in correct notation.
> For example:
>
> CD1_2   =          -0.00000007 / Matrix distortion element
>
> But the final per-chip FITS files created during the ingestion show this
> entry:
>
> CD1_2   =                -7e-8
>
> That is, the dot that is required as part of the FITS floating point number
> specification is missing. The problem seems to arise in the very last stage
> when eclipse.image.image.save() is called, which in turn uses
> qfits_header_dump() to write the FITS header. While the header variable on
> the python level stores the values actually as floating point numbers, the
> header structure passed to the C routine qfits_header_dump stores the values
> of the FITS header entries as character strings, so there must be some
> conversion somewhere (possibly implicit?).
>
> In fact, using python's str() function to convert the floating point
> number -0.00000007 to string representation, one gets '-7e-8', which is
> excatly what is shown in the resulting FITS files and causes the problems
> with preastrom due to the missing dot.
>
> What is the best way to fix this?
>
> Cheers,
> Hans
>
> _______________________________________________
> Issues mailing list
> Issues at astro-wise.org
> http://listman.astro-wise.org/mailman/listinfo/issues
>
>