[Issues] floating point format again...
John P. McFarland
mcfarland at astro.rug.nl
Tue Jul 17 18:29:43 CEST 2007
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
>
>
More information about the Issues
mailing list