[fitsbits] problems with fits readers

[Eric Greisen]

At the behest of some individuals who read the aips output FITS files
closely, I made a change so that variables we keep in double precision
internally are shown as double precision floats on output FITS
headers.

A user reports trouble with this:

My problem is that it seems that neither the 'kvis' task in KARMA,
or DS9 (the display and analysis programme used in conjunction with
Chandra and XMM data analysis, see http://hea-www.harvard.edu/RD/ds9/), 
can handle correctly this new format.

She did a diff on the headers from the current AIPS and the previous
one and gets

diff 03dec-version 04dec-version
16,17c16,17
< BSCALE  =    3.16551153040E-06 /REAL = TAPE * BSCALE + BZERO
< BZERO   =    1.02674588561E-01 /
---
> BSCALE  =    3.16551153040D-06 /REAL = TAPE * BSCALE + BZERO
> BZERO   =    1.02674588561D-01 /
22,23c22,23
< OBSRA   =    2.50952791667E+02 /Antenna pointing RA
< OBSDEC  =    1.72636944444E+01 /Antenna pointing DEC
---
> OBSRA   =    2.50952791667D+02 /Antenna pointing RA
> OBSDEC  =    1.72636944444D+01 /Antenna pointing DEC
27c27
< CRVAL1  =    2.50952791667E+02 /
---
> CRVAL1  =    2.50952791667D+02 /
32c32
< CRVAL2  =    1.72636944444E+01 /
---
> CRVAL2  =    1.72636944444D+01 /
37c37
< CRVAL3  =    1.49399000000E+10 /
---
> CRVAL3  =    1.49399000000D+10 /
42c42
< CRVAL4  =    1.00000000000E+00 /
---
> CRVAL4  =    1.00000000000D+00 /

The FITS standard makes it clear that either format is acceptable and
that neither the E nor the D STATE anything about precision (although
they do carry an implication to knowledgable readers).

I guess that I will have to roll back the change to AIPS in defense,
but I would like to urge authors of FITS readers to check their code
immediately to make sure that the D form is understood as well as the
E form.  This has been a part of the standard since day 1.

Eric Greisen