[QUANTITY] Quantity "arguments"

[David Berry]

Ed,
  I think we are getting close to the crux of our disagreement here. Your
model seems to come down to a list of data values and a corresponding
list of world coordinate positions. But it doesn't easily give access to
an algorithm for converting an arbitary list index value into a
corresponding world coordinate value. By comparison with FITS-WCS paper
III, your model is like the "-TAB" algorithm, and mine is like all the
other algorithms.

If the Quantity model includes an algorithmic description of the
"projection" from list index into world coordinates, then this description
can always be used to generate the world coordinates at the pixel centres.
But on the other hand, if the Quantity model simply stored the pixel
centre world coordinates in a list of numerical values, then this list
could not in general be used to re-create the algorithm. That is, you
loose information by storing lists of numerical values rather than the
underyling projection algorithm. And since unnecessary loss of information
is a bad thing, I would say that the Quantity model should store the
algorithm whenever possible, and only store the numerical values as a
special case when no algorithm is available.

There are many situations in which client software may legitimately be
interested in positions in between the tabulated values. One example
would be drawing (say) an (RA,Dec) coordinate grid over a 2D image. The
curve drawing algorithm needs to be able to find the pixel coords (and
thus the screen coords) at any arbitrary (RA,Dec) position, not just those
corresponding to pixel centres. Another example would be re-projecting an
image - there is no reason to suppose that each input pixel centre will be
projected exactly onto an output pixel centre (in fact they hardly ever
will be).

And there are others...

So I think we need a model which naturally describes algorithmic
transformations between continuous coordinate systems, and does not impose
any restrictions on the axis values which can be transformed. I would
maintain that the FrameSet model I have been describing does just that.

David




> The Argument/Quantity/Accuracy holds a BinWidth for binned quantities
> and/or Error, positiveError, or negativeError for measurements with
> errorbars along the coordinate.  These may be  arrays or single values.
> BinWidth and Errors can be combined to describe errors in the
> calibration of the coordinate bins.  If the coordinate requested is near
> a coordinate and within the Accuracy tolerance of it, then the value at
> that coordinate is returned.  If there are overlapping error bars, then
> several points should be returned.  If the requested coordinate value
> lies in the gaps between the errorbars or between truly discrete
> measurement values then noData should be returned by the core API. But,
> we can also have a mode that allows for the two (or more) adjoining
> points  to be returned along with the noData  flag.   This mode may be
> useful also when the request is out of range and you want to know  the
> value on the first data point that is within range.
>
> If the application wants to do interpolation despite there not being any
> appropriate data (say we have nuclear cross-sections in the lab at
> T=1E9,3E9,1E10 K and one wants to interpolate to 6.3E9 K), then the
> application may interpolate the "off" points. Or, the service that
> provides the data may include interpolation service when appropriate.
> In this example, however, such interpolation is dangerous because major
> cross-section "resonances" can fit between the discrete measurements. So
> this option should be used with caution.
>
> Ed
>
>

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX