[fitsbits] start of Public Comment Period on CONTINUE Long Kwd convention

[Mark Calabretta]

On Fri, 26 Jun 2015 12:51:45 -0400
"Tom McGlynn (NASA/GSFC Code 660.1)" <tom.mcglynn at nasa.gov> wrote

> > Options (a), (b), and (c) can be eliminated on the grounds of
> > impossibility, implausibility, or impracticality.  Option (d) is
> > practical.
> <nit> Why are arrays of longs less plausible the arrays of ints?  
> Support for
> 64 bit integers is pretty common these days </nit>

OK, I got carried away with the "im" words.  It doesn't change the
argument though.  (And they're actually long longs.)

> > The same argument applies to floating point types, although there is
> > even less likelihood that more than 70 digits will be required for
> > those.  In practice, very high-precision floating point values are
> > split as the sum of integer and fractional parts recorded separately,
> > e.g. MJDREF = MJDREFI + MJDREFF.  This is despite the fact that 70
> > digits is more than enough to accomodate the precision required.  Thus,
> > continuation is not needed for floating point keyvalues.
> <nit> These is the possibility of complex values in the header.  I don't 
> know if these have ever been much
> used, but I think they bring the possibility of a need for more space  
> for floats from infinitesimal to extremely remote </nit.

Have you ever seen a header with a complex keyvalue in it?  I haven't.
And as for "integer complex"...  In any case, the above argument still
applies even with 33 digits each for the real and imaginary parts.

> > The current proposed change to the standard allows *any* string-valued
> > keyword to be continued, with six exceptions: XTENSION, TFORMn, EXTNAME,
> > TTYPEn, TDISPn, and TNULL.  Potentially, therefore, FITS readers must
> > always use fits_read_key_longstr(), or its equivalent, to read a
> > string-valued keyword (except for the six), and will be responsible for
> > freeing the memory allocated for each and every one.  The same goes for
> > keycomments also if they are allowed to grow in size.  There will also
> > be side-effects arising from the need to change the way that string
> > keyvalues are stored, e.g. as struct members.
> 
> I'm a little confused by this.  When long strings are supported I would 
> assume a program that supports them (including using CFITSIO) reads the 
> string value using it's standard mechanism and if it sees a trailing '&' 
> some special software kicks in.  For the vast majority of string values, 
> no special handling need be done.   Right now CFITSIO supports long 
> strings for virtually any string keyword. Nothing is changing here.   
> Clearly libraries which don't support long strings will need some 
> update, but for the libraries which do the only different may be that 
> the support is always enabled rather than being triggered by the 
> LONGSTRN keyword or some user flag.

The FITS standard defines the data type for all recognised keywords,
and this allows an application programmer to decide in advance how to
read a keyvalue.  So, for example, CRVALia is floating point and
WCSNAMEa is a string limited to 68 characters in length.

Using cfitsio, to read CRVALia the app programmer currently uses
fits_read_key_dbl() (or equivalently fits_read_key(..., TDOUBLE, ...),
or possibly the float equivalents with the potential loss of some
precision, and provides an appropriate variable to hold the value.

Currently, the appropriate function to read WCSNAMEa is
fits_read_key_str() (or equivalently, fits_read_key(..., TSTRING, ...)),
and the programmer provides a char[] of at least 68+1 characters to hold
it.  However, if WCSNAMEa were allowed to grow indefinitely long, then
this would no longer be adequate, essentially the resulting "loss of
precision" here equates to losing the nether part of the string, and
existing code would potentially be broken.  To repair it, or when
writing new code, because the programmer has no way of knowing in
advance whether WCSNAMEa will be continued or not, he must assume the
worst and always use fits_read_key_longstr(), which works in quite a
different way to fits_read_key_str().  In fact, the latter function
would no longer be appropriate for reading anything other than XTENSION,
TFORMn, EXTNAME, TTYPEn, TDISPn, and TNULL.

In this respect, FITS strings and continued strings are different data
types.  The CONTINUE proposal, as it now reads, effectively amounts to
changing the data type of all string-valued keywords recognised by the
standard, apart from those six.

To be clear, I'm not against CONTINUE, just the current wording of the
proposed addition to the standard.  Also, I am curious as to how the
equivalent of fits_read_key_longstr() would be implemented in Fortran.

Regards,
Mark Calabretta