Subject: about OGIP/93-001

From: Lucio Chiappetti <[email-masked]>
Date: Mon, 26 Apr 93 11:44:25 -0400

Finally I had time to read memo OGIP/93-001 and all related
correspondence, and I'll try to summarize my comments below (in a few
cases I will just repeat comments already raised by other people, in order
to strengthen support to such opinions).

-----------------------------------------------------------------------------   
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E          
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager           
Internet: [email-masked]            |           FORTUNAE SUAE            
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |                                    
Bitnet:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------   

A) A STANDARD ON PHYSICAL UNITS - WHAT FOR ?

First of all I'd like to have a clearer idea of what is the PURPOSE of
such a standard. I can think myself of the following motivations :

 0- to define the content of TUNITn (CUNIT, BUNIT) keywords (but this
    is not an exhaustive motivation, just an implementation)
 1- these unit keywords provide (human-readable) DOCUMENTATION about the
    file content
 2- these unit keywords are used to annotate plots, and to appear in printouts
    (still the emphasis is on human legibility, though software-aided)
 3- for autoscaling by programs when reading the data (this implies some
    form of parsers in software)

Personally I would put emphasis on motivations 1 and 2, and not be overly
concerned about motivation 3, and pursue this systematically in the
comments below.

I would also say that I regard the question of units a "third order" issue
(this does NOT mean a standard in this area is not important, it IS important
for users to interpret the files, but is not essential in a way that not 
having it will hinder software development, or data usage by existing
software). I would for instance regard as a "second order" issue the 
definition of STANDARD NAMES for PHYSICAL QUANTITIES (and I will cover this
in a separate mail) and as a "first order" issue yhe definition of what are
the basic file structures to be discussed within HEAFITS (and what are 
instead best left outside; this too I intend to cover in a separate mail)

B) AESTHETICS, PROMOTIONS AND DEMOTIONS ETC.  (comments to Tab I-II-III)

B1)

A minor comment to Tab. 1. Given for granted Clive Page's comment on the
low (--> 0) frequency of electric conductance in astronomical data, and
also given for granted that "S" may be confused with "s" for second in a
case-insensitive environment I wonder why "siemens" are abbreviated "siemen". 
I do not see any reason to truncate the final "s" since there is other-
wise no limitation to 6 character of the unit string. I do not believe
poor Wilhelm and Werner Siemens deserve this truncation (although the
SI decided that poor Alessandro Volta be subject to truncation in giving
his name to the electric potential unit).

Perhaps it would be useful to spell a clear rule like this :
the unit string is the standard SI (or cgs or whatever) abbreviation (e.g.
s, kg, Wg, cm, keV) in all cases where this is : a) in printable latin
characters, b) not ambiguous considering case sensitivity ; in all other
cases the long form of the unit name shall be used (so you correctly
use ohm, siemenS, angstrom, deg)

B2)

As an application of the previous rule, I'd like to see the form "micro"
instead of "u" used as the 10**-6 prefix. Therefore "micros" for 
microsecond and "microm" for micrometers etc.

B3)

Concerning table I, I regard almost all the second half of it (from Volts
to Henry) of unfrequent use in astronomy (the same is true for Ampere and
mole in the first part), anyhow it is fine by itself.

I would promove to table II the following units :

micros and ms (microsecond and millisecond)
cm (centimetre, for NH in atoms/cm**2)
pc, kpc, Mpc (parsec, kiloparsec, megaparsec)
Jy, mJy, microJy (jansky, milli- and micro-jansky)
photon (for dN/dE photons/cm**2/s/keV and alike)
(perhaps also grams, eV and MeV)

I would also appreciate a dimensionless "atom" to appear, still in order
to express column densities like NH = 10**22 atom/cm**2).

C) COMPOUND UNITS

Since I am giving emphasis on use of strings for annotating plots and
printouts, in order to keep the label short, I do not like parentheses 
around exponents. Actually I'd even accept to drop the ** power operator, 
and have cm2 instead of cm**2 etc., having forms like  
erg/cm2/s/Hz or erg cm-2 s-1 Hz-1.
I believe they are fully acceptable for plots (even at publication 
quality) and work printouts. In all cases a smarter software (plotting,
or word processing) must reformat them into superscripts, this is still
possible if one assumes that a (eventually signed) number following a
plain unit is to be intended as superscript.

D) ANGULAR QUANTITIES

Yes I agree to deprecate hh-mm-ss and similar sexadecimal notations for
STORAGE (however they are valid for display). I'd also like a definition
("typedef") of special data types for "angles" (decimal degrees ?),
"times" (seconds or fractions thereof) and "dates" (MJD) to be associated
to a given column table or header keyword (particularly the latter however
applies nto to FITS files but to some package's native internal format).

For angles the question is then what to recommend (radians vs degree).
I presume the discrimination should be the number of significant figures
in the most restrictive double precision binary representation around.
I give for granted that angles are represented as a REAL*8 value "in some
units".  REAL*8 are "about 16 decimal digits" on VAX D_FLOAT and IEEE,
"about 15" on VAX G_FLOAT (it is disappearing on Alphas, isn't it) and
I presume also on IBM VM (but I am not sure).

As an arcsec is 2.777777E-4 deg, assuming an angle is limited to 0-360 deg,
this makes nnn.fffxxx with xxx=278 at least necessary to keep the arcsec
resolution with some precision, i.e. 9 decimal figures. This is more than
usual single precision, hence double precision is needed for angles in
degrees.
This is even more true if one uses radians; an arcsec is 4.8E-6 rad.
Now, what is the resolution we want to keep in general, a milliarcsec ?
a microarcsec ? 
Depending on this, degrees might be preferred if we get close to the
limit by about 2 decimal digits.

E) UNIT PRESCALING

Yes, pre-scaling like 10**44 erg/s is needed, and must not be interpreted
by software (in order not to overflow on 1.0E-38 to 1.0E38 machines ...)
i.e. no TSCAL and alike.
I actually wonder whether even in IEEE floating point data special
precautions are to be taken to avoid values outside this range, given
that non-IEEE machines are often limited to the above range for single
and ofter double precision ... again the most restrictive machine rules)

In this case unfortunately my "labelling argument" fails (I can write
10-26 W/m2/Hz, but not 1044 erg/s ...  is 1E44 any better than 10**44 ?)

I regard prescaling is just a reminder for humans (so I would not be 
concerned too much about eV, MeV instead of keV and so on). In general
I foresee some manual handling by user, based on the "dopcumentation"
provided in the file,if the units AND prescaling used does no match
that supported by my s/w( I would not overload my s/w with complex
parsing routines trying to cope with many cases ... "build a system
that even a fool can use, and only a fool will want to use it").
E.g. I have a set of programs which can handle photon spectra in
photon/cm2/s/keV, wavelength spectra in in 1E-14 erg/cm2/s/angstrom,
frequency spectra in mJy (1E-26 erg/cm2/s/Hz) and nu-Fnu spectra in
erg/cm2/s. If I receive from somebody a spectrum in other units (say
1E-16 erg/cm2/s/keV) it is my business to scale it in advance.

In principle I'd favour to limit prescaling to powers of ten, but I am
concerned about powers of 2. Often spacecraft clocks are in steps of
some 2**-n s, and binning of time profiles, accumulations of spectra,
etc. are in some multiple of that. I personally believe that for plotting
one best uses just (decimal fractions of) seconds, and for internal
handling a different convention (storing the time resolution in some
kewyord) shall be devised.

F) PIXELS, BINS etc.

I am happy to leave with the ambiguity of pixels as units of area and
length. They are clear by context (if I say 70 photons/pixel I mean an
unit of area; if I say "a box of 7*10 pixels" I mean an unit of length.

"Bin" is a synonym for pixel when speaking of 1-d histograms (i.e.
distribution y=f(x) with x in bin number; as z=f(x,y) with x,y pixel number.

Concerning bin and pixels, I also would like to raise some additional
issues.

Sometimes one is happy to operate on bins or pixels as provided in
the image (2-d x=f(x,y)) or histogram (1-d y=f(x)). This is e.g. the
case of Burst Length or Rise Time spectra, in which one happily works
in whatever ADC channels are provided and is not concerned with how
many microsecond is Rise Time channel 18.  In some other cases instead
one may want to work in RA,Dec instead of x,y pixels (and this is
covered by the well-known WCS stuff); or perhaps his image is a chi-
square map with x,y logNH and alpha ... or one wants energy in keV
or wavelength in angstrom instead of channel number.  I am not sure
about the WCS being able to accomodate the latter cases, probably yes.

I need to read it again, specially for things whether the corner of
a pixel (bin) is 0, 1, or 0.5 and alike.

However there are intermediate cases of conversions, between "world"
coordinates (RA,DEC or KeV) and "arbitrary" coordinates (image pixels
or histogram bins), that is when some "standard detector coordinates"
are used. Let us consider for example the case of a 1024*1024 Detector
Pixels (DP), from whose datastream I accumulate a 256*256 image, zoom 2,
covering the central 512*512 DPs. If I want to know some position-dependent
correction factor, I need to use the position in DPs, not in "image pixels"
(1-256).  Likewise a detector may bin energy in 512 PHA channels, but the
onboard or ground s/w may integrate it in 64-bin spectra, but to know
channel boundaries or spectral response I'll need to refer to PHA channels.

In the latter case it looks a quite widespread custom is to call
"channels" the original detector PHA channels, and "bins" whatever
multiple thereof (including 1* multiple).
I've seen the proposal to introduce a similar jargon for images, calling
"pixels" the "detector pixels" and "cells" whatever multiple thereof, but
I believe this is NOT a widespread usage.

I wonder whether such distinction shall be introduced at "unit string"
level - or "third order" (differentiating "BIN" and "CHANNEL", "PIXEL" 
and "CELL" etc.) or instead at "quantity name" level (a "second order"
question) putting in the column heading or otherwise appropriate kewyord
a different name (for images it might be DETECTOR_X, DETECTOR_Y, or
X_DET, Y_DET instead of ARBITRARY_X, ARBITRARY_Y or just X, Y, although
I'm not happy with they way they sound, and even less I can find a
satisfactory arrangement for PHA spectra).

*** that's the end ****

---

From: "Clive Page, Leicester University, UK" <[email-masked]>
Date: Mon, 26 Apr 93 14:40:56 -0400

Section (D) of the message from Lucio Chiapetti displays what I think is
a fundamental misunderstanding of the way that floating-point arithmetic
works.  The precision you obtain is independent of the units you use (to
within at most a factor of two), provided the numbers don't stray
outside the permitted range.  This is most unlikely to happen with
angles whether you use radians, degrees, revolutions, or even
microgrades. 

My preference is for radians simply because trig functions are normally
defined to operate on them, and one can lose accuracy by repeatedly
converting degrees to radians and vice-versa.  My preference is to use
internal storage to suit the machine, and convert to/from external forms
(decimal degrees, hh:mm:ss, or whatever) to suit the user.  The internal
workings of all machines that I know about are more efficient if angles
are stored internally in radians. 

As to the need for DOUBLE PRECISION: in my experience most astronomical
positions are only precise to an arc second or so, so that REAL storage
is usually sufficient. 

A note for Lucio: 

The REAL number format of IEEE arithmetic (and VAX arithmetic is very
similar) uses 23 bits plus a sign bit to store the magnitude.  But
because the exponent is normalised, i.e. adjusted to make the mantissa
as large as possible, its leading bit is always one and is therefore not
stored (it is called the "hidden bit"). There are therefore effectively
24 bits, giving a resolution of 1 in 2**24, i.e. around 1 in 1.67e7. If
our angles are normalised to a sensible range, the largest angle we need
to handle is 360 degrees (or 2*pi radians) which has in REAL format a
least-significant bit error of around 0.05 arcseconds.  You can test
this for yourself by storing 2*pi in a REAL and adding small numbers to
it until it no longer equals two pi any more: I think that you will find
that the smallest number you have to add is 2.4e-7, which converted from
radians to arcseconds turns out to be 0.05.  Althernatively if you store
360.0 in a REAL and do the same I think you will find that the least-bit
resolution is very nearly the same. 

Regards 

Clive

---

From: "Wayne H. Warren Jr. 286-5419" <[email-masked]>
Date: Tue, 27 Apr 93 08:41:50 -0400

> The precision you obtain is independent of the units you use (to
I checked this out for units that I would have thought disproved it,
but it came out the way Clive said.  I converted 0.001 arcsecond (a
typcial proper-motion value) to degrees, which comes out to 2.78E-07,
still well within 32-bit single precision.

> positions are only precise to an arc second or so, so that REAL storage
I disagree with this, unless you're sure that you won't need positions
to the accuracy currently available in the new astrometric catalogs.
Single precision truncates to about 0.36 arcsec (depending on the RA).
The new catalogs are better than this.  I suggest storing *astrometric*
equatorial positions in double precision (REAL*8) to be safe.

---

From: [email-masked] (William Pence)
Date: Wed, 28 Apr 93 16:32:28 -0400

>equatorial positions in double precision (REAL*8) to be safe.

I don't see what the issue is here.  The designer of a particular FITS
file should be able to choose to use whatever precision is required
when storing the RA and DEC values in the file.  In some cases this
will require using full double precision values, but in other cases
single precision floating point, or even scaled integer*2 values (which
can give a precision of about +/- 20 arcsec) may be more than adequate
and may be usefully used to reduce the total size of the FITS file.

FITS readers which process the RA and DEC values in some way should in
general read the RA and DEC values internally into double precision
variables, so as to not lose any precision.

-Bill Pence