Subject: OGIP/93-001 - 3 Specific Questions

From: [email-masked] (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
Date: Wed, 21 Apr 93 05:08:39 -0400

RE: OGIP/93-001 (Specification of Physical Units within FITS files)

Thank you for the comments etc received so far. Most of these seem to 
be relatively straightforward suggestions for the promotion, demotion 
or addition of unit strings. Lorella & I will attempt to summarize
and give our reactions (based either on some form of consistency or 
consensus arguments) in a week or so.

However there are 3 (slightly harder) issues which have been raised (all
by Jonathan McDowell), but received little debate. Thus I'd like to raise 
them again here since I'd be interested in your collective opinion.
(Replies to the [email-masked] exploder please)

A) Jonathan correctly pointed out that pixels are used as units of 
   both length and area. 
    - Is everybody happy with such an ambiguity ?
   	==> Personally, I dont like it much, but have a feeling that it 
        may be so engrained in FITS files & brains currently in circulation 
        that it will be hard to break. 
    - Is there any viable alternative ?
   	==> I believe the correct definition of a pixel is in terms of 
	an area, thus dislike the scheme whereby a 'pixel' is redefined as 
	a unit of length, and 'pixel**2' as a unit of area. Thus the only 
   	option is to come up with a name/unit for the side of a pixel
	(and please nobody suggest 'pixel**0.5' !). 
	I think we have to live with the ambiguity....

B) Jonathan felt that units raised to negative powers could be better 
   expressed using the format 'W m**(-2) Hz**(-1)' rather than 'W /m**2 /Hz' 
   since any possible ambiguity is removed.
    - How do others feel ? 
	==> Personally I like this suggestion, especially since I consider 
 	it to remove the necessity of Bill Pence's earlier suggestion that all 
	multiplicative units be separated by an asterix.
    - Are the brackets necessary ?
	==> I find the string easier to read & parse if they are included, 
	thus suggest yes, they be mandatory for all indices.
    - If accepted should it then follow that ALL unit strings must conform 
      to this syntax, and thus that the '/' character is never used again ?
	==> I suggest yes, lets simplify the parser and get rid of the '/'

	[==> Regarding the 2nd half of Jonathan's point 4, I assume that most 
        people agree that in the case of units raised to fractional powers, 
	then it preferable to express those fractions as decimals.]

C) Finally, Jonathan also asked about the inclusion of numerical factors 
   within the units string. Specifically he was concerned about preventing 
   under/overflows
    - Are '10**(44) erg /s' and '10**(-26) W /m**2 /Hz' acceptable units ? 
	==> (apart from the use of the '/' -- see B) I'm undecided about this, 
        but see that it could lead to additional interesting possibilities 
	such as 
	- the elimination of the need for SI prefixes 
		eg '10**(6) eV', '10**(-10) m'
	- even implicit unit conversions 
		eg '3600 s', '0.0254 m'
	==> personally I *think* I like the idea of allowing factors of 10 
	to be specified in this way, but feel rather uneasy about any other 
	numerical factors. In either case, however, I suggest that if 
	allowed such factors were only allowed to be placed at the 
	beginning of the string.
    - But do we really want to start such a trend ?

Ian M George
([email-masked])

---

From: [email-masked] (BARRY M. SCHLESINGER)
Date: Wed, 21 Apr 93 08:47:29 -0400

The discussion on numerical factors within units, as summarized by Ian

>    - But do we really want to start such a trend ?

The current BINTABLE proposal provides for the TSCALn and TZEROn 
keywords, which can be used for scaling in the same way as the same 
keywords for the ASCII table extension and as BSCALE and BZERO for a 
data array.  Thus if the values in column 6 were in units of 
10^(-10)m, then one could use 

TSCAL6  =               1.E-10
TUNIT6  = 'm       '

This way, only standard units are used as values for TUNITn, but the 
quantities in the table can still be of reasonable magnitude.  Note 
that TUNITn (and BUNIT) give the units of the physical quantity 
derived by applying the scaling transformation to the value contained 
in the FITS file.

			Barry Schlesinger
			NSSDC/NOST FITS Support Office