[QUANTITY] Justification for Matrix Quantities (Was: Re: [QUANTITY] Requirements and apology)

[Brian Thomas]

On Tuesday 04 November 2003 05:26 am, David Berry wrote:
> Ed,
>
> > You are discussing a flux quantity that is dependent on frequency (I
> > prefer hasArgument but they are synonomous).  Frequency is also a
> > quantity.  It is something that is measured (in this case, by
> > measurements on a calibration lamp).  Normally one would simply have an
> > array of flux and an array of frequencies and you would say the flux
> > (quantity array) is dependent on the frequency (quantity array).
>
> 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.

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


> Why not say that flux is a function of focal plane
> position, which is a function of sky position, which is a function of
> pixel index? I'll reiterate that in my opinion, the only truely
> independant variable we have here is pixel index, since that is what is
> used to access the actual numerical values, and that the best way to model
> this is to store both the dependancy of sky position on pixel index and
> also the dependancy of focal plane position on pixel index.

	Sorry, not quite following you here. I agree that i, j are the only truely independant
	variables. All others are dependent on them. But does that matter? (or did I mis-understand
	something?) 

	IF quantities have mappings that they carry along with them, then I see no problem with 
	creation of a data locator, that does the translation for the user (programmer), or simply using
	any "valid" set of coordinates, for example, from the above, all the following statements about 
	what F is a function of are true (via a mapping translation mechanism):

	F => F (S ) => F(RA,DEC) => F(I,J) => F(i,j)

	The programmer should be capable of specifying any  of the self-consistent (right word?)
	"coordinate systems" sets:  {S},{RA,DEC}, {I,J} or {i,j} to find the flux of interest.


>
> So far this message has talked exclusively about transformations based on
> pixel *index*, but the model should provide equivalent facilities for
> pixel *value* - i.e. it should describe how to move from what we have
> (pixel value) to what we want (e.g. flux).

	We think exactly alike here, but our semantics differ. We consider the "value" of the 
	quantity to be the "value" of the pixel when the quantity is "pixel index".

	I hope that explains our position better. I look forward to your response.

	Regards,

	=b.t.

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