Subject: TZERO applied to complex data types in binary tables.

From: mcs at goblin.caltech.edu (Martin Shepherd)
Date: 6 Apr 1993 21:31:06 GMT

In the NOST FITS standard document (Nov 6, 1991) a list of types for
which TSCAL and TZERO are undefined is presented (Page 42). Complex
types are not in this list. How should TZERO be applied to complex
values? 

Should TZERO be treated as a real number:

	  A+iB  ->   (TZERO + A x TSCAL)  +  i(B x TSCAL)

or should it be applied to both complex parts as:

	  A+iB  ->   (TZERO + A x TSCAL)  +  i(TZERO + B x TSCAL)  ?

I am going to assume the former for now but would appreciate some
clarification.

Martin Shepherd   (mcs at phobos.caltech.edu)

---

From: dwells at fits.CV.NRAO.EDU (Don Wells)
Date: Tue, 6 Apr 1993 23:32:11 GMT

In article <1pssqqINNnv4 at gap.caltech.edu> mcs at goblin.caltech.edu
    (Martin Shepherd) asks: "... How should TZERO be applied to
    complex values? .." [in tables]

The Basic FITS Agreement specifies that value fields will utilize the
conventions of Fortran-77 list-directed READs. In this case the
relevant text is lines 18-24 on page 13-14 of ANSI X3.9-1978
"Programming Language FORTRAN":

"When the corresponding list item is of type complex, the input form
consists of a left parenthesis followed by an ordered pair of numeric
input fields separated by a comma, and followed by a right
parenthesis. The first numeric input field is the real part of the
complex constant and second is the imaginary part. Each of the numeric
input fields may be preceded or followed by blanks.."

While this is surely the proper pedantic answer to the question, it
does make me rather nervous because it is improbable that there is any
FITS reader that would properly construe such syntax. I advise caution
in this matter.
--

Donald C. Wells             Associate Scientist        dwells at nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Tue, 6 Apr 93 19:21:31 EDT

>I am going to assume the former for now but would appreciate some

The first formula is correct in a strict algebraic sense, but I think
the second formula is more appropriate in FITS applications.
Some computer languages don't support a complex data type, and most do
not support the double complex (M) FITS data type, so many FITS readers
will probably internally interpret a '1C' binary table column as a '2E'
column, and a '1M' column as a '2D' column.  Then one would more naturally
want to apply the second formula to scale the input FITS values.

As a practical matter however, it doesn't make much sense to scale a
floating point binary table column, does it?  Why not just write the
scaled values directly in the table, and thus save the scaling overhead
each time the FITS file is read?

-Bill Pence

---

From: thompson at serts.gsfc.nasa.gov (William Thompson)
Date: Wed, 7 Apr 1993 21:57:09 GMT

>Martin Shepherd   (mcs at phobos.caltech.edu)

I would also assume the former, based on looking at it as an equation, i.e.

	Ctrue = Tzero  +  Cfits * Tscal

	Cfits = A  +  i * B

	===>	Ctrue = Tzero + (A + i*B)*Tscal
		      = (Tzero + A*Tscal) + i*B*Tscal

I work in IDL.  Our software works by choosing what kind of datatype to assign
to a FITS header record from the way it is written, rather than by making an a
priori assumptions.  Thus, we would be able to handle a case where either or
both of TZERO and TSCAL were themselves complex numbers, so long as the
recommended fixed formats were followed (section 5.3 of the NOST standard).
However, a strict reading of the FITS standard does not appear to allow this.

Bill Thompson