[QUANTITY] Justification for Matrix Quantities

[David Berry]

Brian,

> > If you have a simple 1D array of numbers, your starting point is surely
> > to say the pixel value is dependent on the pixel index. The measured
> > discrete pixel values are the fundamental thing we are describing here,
> > not the underlying continuous physical function of flux on frequency. The
> > Quantity meta-data should allow you to move from what you *have* (i.e. the
> > dependancy of pixel value on pixel index) to what you *want* (e.g. the
> > dependancy of flux on frequency).
>
> David, all,
>
> But pixel index *can* be a quantity. It most certainly is not simply
> an index of a dimension. It does have units ("unitless") and data type
> ("integer") and error ("no error, exact value"). The pixel index can be
> a function of any set of integer numbers (admittedly its usually
> positive) but there is no set understanding of where that pixel index
> number starts. It may be 0 or 1, (or possibly something else if you have
> weird numbering) whereas the index of that dimension should start always
> at some common conventional value (I prefer "0"; purely speaking here as
> a C programmer). For example, the underlying index could maps to the
> pixel index as follows:
>
> index  0   1    2    3    4     5     ...   N
> pixel   1   2    3    4    19   20    ...   M
>
> where I can choose to make the mapping as I like between the integers.
> In the case above, I have "reordered" the placement of the 19th and 20th
> row of pixels to their underlying location in the data array at position 4,5.

I'd go along with you here, but I would translate what you're saying into
what (for me) would be a simpler concept that "the values stored within
a pixel array can themselves be pixel indices into another pixel array".
[A detail - just because something is dimensionless does not mean it
doesn't have units - "angle" is dimensionless but has units (rad.s,
degrees, etc). One could possible argue that a value which represents a
count (such as pixel index) should have a "unit" of the thing which is
being counted. Thus a pixel index value of 10 could be thought of as "10
pixels" i.e. the units would be "pixel".]


> > One point to note is that whilst "what we have" is always the same (i.e.
> > we have the dependancy of pixel value on pixel index), there may be
> > several options for "what we want". For instance, for a simple CCD image
> > of the sky, we may want the dependancy of (RA,DEC) on pixel index, or
> > alternatively we may want the dependancy of focal plane position on pixel
> > index. Presumably, in your model you would express this by saying that
> > flux is a function of sky position, which is a function of focal plane
> > position, which is a function of pixel index? How do you decide on the
> > dependancy order?
>
> 	Dependancy is seen by nesting the order of the functions (quantities). Using
> 	your example:
>
> 	F ( S )
>
> 	is the flux quantity "F", "S" is the sky position quantity where S is a function
> 	of RA, DEC quantities, ie.
>
> 	S => S(RA,DEC)
>
> 	and RA, DEC are functions of respective pixel indices I, J, e.g.
>
> 	RA(I,J)
>
> 	and
>
> 	DEC(I,J)
>
> 	and I, J are mappings from underylying "matrix' indexes i, j ,eg.
>
> 	I(i,j)
>
> 	J(i,j)
>
> 	where i, j by convention are whole number ordered sets that identify the location
> 	of the data.

What about focal plane coordinates (e.g. (x,y) in millimetres from the
telescope boresight)? The flux could equally be thought of as a function
of focal plane position. And there could potentially be other coordinate
systems - for instance, if you take a cut-out from a big image you could
think of flux as a function of pixel index in the cut-out image, or as
a function of pixel index in the original entire image. My question is how
does you scheme cope with what FITS-WCS calls alternate axis descriptions?
A general solution should be able to cope with an arbitrary number of
alternate axis descriptions.

Using the sort of [WCS] idea I've mentioned in the past, this sort of
Quantity would have a WCS component which could be represented as a tree:

                       PIXEL
                       / | \
       ----------------  |  ------------------
       |                 |                   |
      SKY           FOCAL_PLANE        PARENT_PIXEL

Each word represents a "Frame" object (i.e. a description of a coordinate
system, e.g. using Arnold Rots STC schema), and each the dashed line
represents a "Mapping" object (i.e. a recipe which describes how to
transform positions between the two Frames connected by the line).
This sort of structure captures all the information regarding axis
dependancies, and is easy to extend indefinitely.

One more question about your scheme... when you have quantities which are
functions of other quantities, do the argument quantities contain actual
numerical values? Back to the CCD example, we have a quantity representing
the flux values - this quantity presumably contains the actual flux values.
In your model this quantity is a function of another quantity representing
sky position. Does this sub-quantity also contain arrays of actual
numerical RA and DEC values?


----------------------------------------------------------------------
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