[QUANTITY] Justification for Matrix Quantities

[Brian Thomas]

	David,

	Overall, some semantics aside, I think we are largely in agreement
	(with one slight difference noted at the bottom of this letter).
	Now, reponses  to your responses. 

On Tuesday 04 November 2003 08:02 am, David Berry wrote:
> Brian,
> [snip]
> > 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".

	I can agree with your quoted statement as well. Thats, in essence, 
	at the root of the idea that quantities may serve as axes (indices) on
	other quantities.

> [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".]

	Agree about dimensionality. Not sure if "pixel" is a unit, but the VO 
	*could* define it as such. I'd rather see "pixel" as a UCD/concept that is a 
	class that inherits from "quantity", but I'm not a stickler on this point.

> [snip]
> > > 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)
> > [snip]

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

	Ah, good question. I think this is handled by having a mapping between
	any one set of quantities (like RA, DEC) and another (like B,L).  Thus, even
	though the "S" the sky coordinate is formally defined as a function of 
	the quantity set {RA,DEC}, the mapping between that set, and the {B,L}
	set allows you to easily specify S as a function of B,L, eg.

	S(RA1,DEC1) == S(B1,L1)

	(or focal plane to RA,DEC, etc)

> A general solution should be able to cope with an arbitrary number of
> alternate axis descriptions.

	Totally agree. I believe this solution allows that. The set {RA,DEC} should
	have a pointer/hook to all mappings that it obeys. The user should be able
	to extend this set from the "canonical" one to include their local mappings.
	Thus, while the mapping {RA,DEC} <=> {B,L} is canonical, and always 
	available, {x,y} <=> {RA,DEC} (mapping between instrument focal plane and
	sky ra,dec) may be an add-on mapping for a particular quantity (say "flux",
	that you measured from a camera).

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

	Yes, I believe we agree, with minor differences in  the semantic difference 
	of "Frame" vs. "set of quantities" is our difference, and that I would
	prefer that some "primary" frame (say pixels in {x,y}) exists within the 
	quantity being interrogated. I desire this primary frame because it has
	impact on the dimensionality of the units. Consider that a F(lambda)
	array has values which are in units of erg cm^-2 s^-1 wavelength^-1. If
	I choose to store F(i) (where "i" is a dimensionless pixel index) then the 
	units are different, e.g. erg cm^-2 s^-1 pixel^-1. Thus, "set" holds information
	of "frame" but further may include information about unit dimensionality,
	and thus, a "primary" set is needed.
	
	(hope that was an intelligible explanation)

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

	Yes, the sub-quantity it may be actual arrays of numerical values OR these 
	values may be generated from an underlying algorithm. 

	Regards,

	=b.t.

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

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128