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

[Brian Thomas]

	Hi David, All,

	Since I wrote this bit into our whitepaper, I'll try to take a stab at it
	(and btw, sorry for being out of contact the past 2 days, I meant 
	to follow up on our discussion on this topic, but other duties have
	intervened). (and If I fail to explain something here, you may want to 
	take a look at our whitepaper on the twiki DM page).

On Friday 07 November 2003 07:48 am, David Berry wrote:
> 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).

	Before I get started, to use your terms, I think you mean "list index"  
	instead of "pixel index". Pixels are the labels (typically integers) that 
	apply to the various list indices when you are describing some quantity
	taken by a camera that has pixels (for example, a photon flux as observed
	by a CCD). There are many other types of multi-dimensional quantities
	that one can conceive, ones that depend on pixels are a minority (although
	an important one for astronomy).

> Pixel index is the only
> indepedant variable we have when considering access to a collection of
> stored data values. 

	I would agree here, if I can change "pixel index" to "list index".

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

	Well, no. Your definition implies that RA, Dec are continuous functions.
	But they may very well be discrete sets of values, such as quantities hold.
	Thus, RA may be viewed as a quantity. The same for Declination.

	I'll try a ground up example to try to explain further.

	Consider a 1-Dimensional quantity of Flux. It has 3 values which 
	where taken by a camera that has one row of pixels. The data in the
	quantity are the set:

	F = { 10.3, 30.4, 50.6 }

	Each of these values has a "list index" associated with it (this is nothing
	more than a convention to label the positions of the values relative to one
	another in the set; as a "C" programmer, I prefer to start labeling with the
	value of "0". Mathematically, the "list index" corresponds to the "matrix"
	or dimensional index). In the above case, let the "list index" be called "i".
	
	Now, I'm sure you will agree, that we can associate each of these flux values
	with a different pixel. Consider that the strip of pixels has a few "dead" cells
	at the beginning, so we start our numbering at "10" instead of say "1". The
	correspondence between i and the pixel number ("pixelNo") would be:

       i    pixelNo
      0         10
      1          11
      2          12

	thus we may speak equally accurately that there is a flux value at i=1 or 
	a flux value for pixelNo = 11 (and the two values are equivalent, e.g. "30.4").
	Thus, we may say the following:

	1. F is a set of values

	2. Each value (in F) is described by a unique value of "i".

	3. pixelNo is a set of values ({10, 11, 12}).

	4. Each value (in pixelNo) is described by a unique value of "j".

	5. IF i == j, they may be used to map between the values in F and pixelNo, and
	we may say  that pixelNo is a function of F (or alternatively, F is a function of pixelNo)
	[Of course, there is implicit in this statement that F and pixelNo are somehow 
	physically connected.] 

	So far in this example, we see that we "pixelNo" may describe a value for a
	quantity F. The question is now, "is pixelNo a quantity itself"? Lets review
	all of its characteristics to determine. PixelNo has be following:

	0. PixelNo is a set of values that map to values in F.
	
	1. PixelNo has dependence on "i".

	2. PixelNo has datatype ("integer").

	3. PixelNo has accuracy ("exact, no error")

	4. PixelNo has units. (While pixelNo is not the best example of this, in past emails
	 I have understood you to more or less take the position  that "pixel" is a unit). Certainly,
	even if "unitless" (my preference) the units stay the same for all values of pixelNo.

	Thus, "pixelNo" looks alot like a "quantity". It has all the properties.

---

	Let me try to sum-up now.

	First, I believe that I have shown that we may choose to equate i, j list indices
	so that one quantity may be used to reference another quantity. In our example
	The data compare to each other as:

list index        0           1           2
pixelNo         10         11         12 
flux                10.3     30.4     50.6

	And we may supply the value "pixelNo == 10" to F to determine  its value. 

	Second, strictly speaking, you are correct about the list indices. They are the only true 
	"independent" variables. PixelNo and F depend on them.

	Third, in this one-dimensional example, each list index describes the "axis" along which 
	the values of a quantity lies. If we can equate the same dependence between the list
	indices for F and "PixelNo", then PixelNo quantity looks alot like an axis 
	(or alternative axis) description for F as well.

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

	I don't think we differ all that much. I think the problem lies in our (Ed+me) perhaps
	perceived "requirement" that every multi-dimensional quantity be described
	(for each extra dimension it has) by another quantity. As I think you outline,
	a simple list index will do as the minimum as its the only independent variable
	that actually describes the dimension. Where we differ (perhaps) is that Ed and
	I  feel that, in order for quantities to be useful for search and data fusion, you
	will need to supply some "physical" meaning to the list index. This is done as 		
	have argued above, and makes one quantity appear to supply the axes values 
	for another (and vice versa).

	Of course, having more than one-dimension requires more explaination, but I'll 
	stop here and see what comments you have.

	Regards,

	-b.t.

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

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