[QUANTITY] Quantity "arguments" (was [TRANSFORM] What is a "frame"?)

David Berry dsb at ast.man.ac.uk
Fri Nov 7 04:48:08 PST 2003

```Ed,
Maybe its just me, but I can't get my head round this whole approach
of a Quantity having arguments which are other Quantities. If a Quantity
represents a collection of numerical values of some single physical
phenomenon, then the only thing that the Quantity "depends on" is the
pixel indices (or some generalisation of pixel index if the data structure
holding the values is not a simple N-D array). Pixel index is the only
stored data values. To say that "a flux quantity depends on (RA,Dec)" is
rather misleading, because it suggests that you have the flux at *every*
position on the sky. On the sky, it is true that flux is a function of
(RA,Dec), but we do not have "the sky" in our data, we have a collection
of pixels, and so flux is simply a function of which pixel you are looking
at. So why do we need the complications of allowing Quantites to have
other Quantities as "arguments"?

The model you present seems to be saying that an axis "is a" Quantity. I
cannot see an axis as a Quantity - I could see it as a "Thing", but not as
a "Quantity". A Quantity is basically one or more numerical values, and an
axis is not a numerical quantity. Saying that an axis is a Quantity is
rather like saying that a tape measure is a distance. You *use* an axis to
describe a quantity, but the axis itself is not a Quantity. There is a
distinction between as axis, and a set of axis *values*, and you do not
need to store axis values within a quantity because they are always
implied by the pixel indices. So having axis values in there just adds
unnecessary complexity.

Here is an alternative model... Considering data points held in some
structure such as an N-D array or tree, there are only *two* things which
we know about a data point; firstly, its value, and secondly; its position
within the structure (e.g. pixel index). So a Quantity simply needs a pair
of components to describe these two things - [UNITS] which describes how
to interpret the *value* of the data point, and [WCS] which describes how
to interpret the *position* of the data point within the data structure.
Both of these components would be optional (although without them all you
could do would be to look at the "raw" pixel value or index). They could
both be implemented using the FrameSet class I have described before.

David

/* Flux as a function of RA,DE or GL,GB positions */
FluxQ
Argument
positionQRef /* The Axes are described by this Argument.
* We chose to use a ref for clarity. */
ValueList
list of flux values /* All of the Flux numbers */
Units
ergs/s/cm2/A

PositionQ /* A two dimensional position */
Argument
Index(NAxis1) /* Index is an object that simply
* generates the numbers 0,1... N-1 */
name
"i-axis"
Argument
Index(NAxis2)
name
"j-axis"
DataFormat
tuple /* Values of positionQ are (i-axis,j-axis) pairs
int
int
ValueList
0,0 0,1 0,2 ...
1,0 1,1 1,2 ...
...
Mapping
/*Mapping always maps ValueList numbers to new numbers.
*Arguments are untouched, but new units may be part of output.
*Generally, the errors need to be remapped too, but pixel numbers
*don't have errors, hopefully. */
PixeltoCoordsAlgorithm
algorithmID
/*Provides unique identification of algorithm to use.
*Perhaps the code could actually be at this URL */
"http://ivoa.net/algorithms/WCS/position/pixelToCoords.c"
Inputs
/* These are parameters of the Algorithm.
*Each algorithm has its own requirements
*on the number of Inputs, their type, and the order.
*In this case, they happen to specify the output frame.*/
Frame1
Equinox
ReferenceSystem
CenterPixel
445 420
PixelsPerArcsec
OutputUnits
/* The algorithm also needs to know the output units */
(hour min sec)
(degree arcmin)
Mapping
/*An alternate mapping to Galactic coordinates. It differs only in
*the input values because I assumed that the algorithm knows
*how to handle both coordinate systems*/
PixeltoCoordsAlgorithm
algorithmID
http://ivoa.net/algorithms/WCS/position/pixelToCoords.c
Inputs
AlternateFrame2
Equinox
"1900"
ReferenceSystem
"GalacticII"
CenterGlGb
CenterPixel
445 420
PixelsPerArcsec
OutputUnits
degree
degree

Ed

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