[Issues] floating point format again...

[Hans Vaith]

Hi John,

thanks for your quick response. I also looked into the issue and found that 
pyfits offers a method to build a FITS card from a string. I wrote a regular 
expression to detect the floating point numbers and modified them as strings 
by inserting the dot manually. Finally, calling the fromstring() method for 
the card seems to do the job:


hdulist = pyfits.open(filename,mode='update')
for i in range(len(hdulist)):
    cards = hdulist[i].header.ascard
    for j in range(len(cards)):
        str_card = cards[j].ascardimage() # extract FITS entry as string
        # check for floating point value and missing dot here...
        # if so , build a new string (i.e., insert dot), then:
            cards[j].fromstring(new_str_card)
            hdulist[i].header._mod = 1 # make sure the mod flag is set
                                       # (not sure if this is needed)
hdulist.flush()
hdulist.close()


Checking the FITS file afterwards shows that the entries now contain the 
missing dot. I will use this as a workaround. Thanks very much.


Cheers,
Hans


On Tuesday July 17 2007 18:29:43 John P. McFarland wrote:
> 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