🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by William Pence Wed, 30 Sep 1992 17:15
triple precision keywords
#38
Author: William Pence
Date: Wed, 30 Sep 1992 17:15
83 lines
4484 bytes
Here at the HEASARC we often need to express keyword values which have
more significant figures than can be stored in a double precision
number.  I have a proposal to handle this, but it may make it difficult
for other data systems to read the value, so I would like some
comments from others before we implement such a system.

A common example of this problem is the Modified Julian Date
which has a value something like 48043.8797453703700742
Currently, we  express this number as 2 separate
keywords, one representing the integer value, and another with the
double precision fractional value, for example:

MJDI    =                48043  /  integer portion of MJD
MJDF    = 8.797453703700742E-1  /  fractional portion of MJD

This however has several disadvantages:
	- it requires 2 keywords = 160 bytes to express the value
	- it clutters up the header with extra keywords which makes it
          more difficult for people to read
        - it makes it more difficult to adopt clear and concise keyword names
          since the last character in the name must be reserved to indicate 
          whether it is the integer or fractional part.
        - it requires that the reading and writing programs make 2 subroutine
          calls to get or put the data.

In principle there is no reason that this information could not all
be expressed in a single keyword value, like:

MJD     =      48043.8797453703700742 /  MJD

The only difficultly with this is that there has been no convenient way
to read or write values in this format, so I have proposed to add (in
fact they are already written) 2 new routines to the FITSIO subroutine
library to solve this problem.  

The new subroutines are:
    ftpkyt    - to write a keyword consisting of an integer + fraction
    ftgkyt    - to read the integer an fractional parts of a keyword value

Both routines have the same arguements:

call ftpkyt(iunit,keyword,intval,dval,comment,status)
          iunit (integer)  - the fortran unit number of the FITS file
          keyword (C*8)    - the name of the keyword to read or write
          intval (I*4)     - the integer part of the keyword value
          dval (R*8)       - the fractional part of the keyword value
          comm (C*48)      - the comment string
          status (I*4) - returned error status

The intval, dval, and comm parameters are input parameters to the ftpkyt 
routine, and output parameters in the ftgkyt routine.

The ftpkyt routine will write a new keyword in f28.16 fixed point format
which consists of an integer plus a double precision fraction.

The ftgkyt routine will read any numeric keyword value (it is not restricted
just to the special keywords written by ftpkyt) and returns the integer and fractional parts in separate subroutine parameters.

This proposal is, I believe, completely compatible with the FITS standard
and any FITS reader should be able to read keywords with this format
however the reader may not perserve all the precision unless is does
some special processing.  This does not worry me too much however since
any software that needs to use the full precision of this keyword is
bound to be highly specialized, hence it is not asking too much to require 
that the software to be able to handle this type of keyword.

The bigger issue that I see is how can the content of this keyword 
be preserved when the FITS file is read into another data system.  For
example, if a FITS image containing a keyword of this type was read and
converted to an IRAF format image file, then I would assume that the
IRAF FITS reader would not choke on this type of keyword, but that it
probably would not preserve the approximately 26 decimal places of precision
in the value.

Can anyone please comment whether keywords in this format would present
problems for their favorite data analysis system.  And if so, are these problems
severe enough that we should not attempt to use this keyword format
in our files?

-Bill Pence
pence@tetra.gsfc.nasa.gov
HEASARC::PENCE
Re: triple precision keywords
#40
Author: Barry Schlesinger
Date: Fri, 02 Oct 1992 15:38
31 lines
2412 bytes
In article <1OCT199212490103@stars.gsfc.nasa.gov>, landsman@stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625) writes...

>    My current IDL FITS reader takes the NOST manual literally.   It
>only extracts the 20 characters in columns 11-30 to determine the FITS
>keyword value.    Any characters in columns 31-50 are interpreted as being
>the imaginary part of a complex number.
> 

This requirement applies only to fixed format.  The fixed format is
required only for values of mandatory keywords.  (At present, there
are no mandatory keywords with floating point values.)  For other
keyword values, it is recommended but not required.  See FITS Paper I,
which says "recommended, and partly required."  This language is
interpreted in 5.3.1 of the NOST standard by saying, "The fixed format
is required for values of mandatory keywords and recommended for all
others."  A well-recognized problem is that columns 11-30 do not
contain enough space to express the full precision of a double
precision floating point number.  The most common, but not standard or
required solution, is to extend the value beyond column 30.  A number
of proposed designs reviewed by the FITS office use this solution.  A
FITS reader that assumes that values of standard optional keywords or
user-defined keywords end in column 30 will not extract correct values
for some user-defined keywords in these data sets. 

Incidentally, EVERYBODY should be certain that their copy of the NOST
Standard is current.  The most recent version is 0.3b.  Some
misunderstandings have arisen because users are referring to 
superseded versions.

				Barry Schlesinger
				NOST FITS Support Office
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads