Thread View: sci.astro.fits
2 messages
2 total messages
Started by William Pence
Wed, 30 Sep 1992 17:15
triple precision keywords
Author: William Pence
Date: Wed, 30 Sep 1992 17:15
Date: Wed, 30 Sep 1992 17:15
83 lines
4484 bytes
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
Author: Barry Schlesinger
Date: Fri, 02 Oct 1992 15:38
Date: Fri, 02 Oct 1992 15:38
31 lines
2412 bytes
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