[TRANSFORM] using algorithm to create axis (quantity) values and frame transforms (Was: Re: [QUANTITY] Justification for Matrix Quantities)

[Brian Thomas]

	David,

On Tuesday 04 November 2003 11:46 am, you wrote:
> > Yes, the sub-quantity it may be actual arrays of numerical values OR
> > these values may be generated from an underlying algorithm.
>
> So there would be no need to store values for the RA and DEC of every
> pixel in an image (just checking)??

	Not exactly. I'll try to explain. 
	
	As we have it, the values in the quantity are generated. Now, if a quantity is 
	specifying the values on an axis, then yes, the axis values are generated from 
	an algorithm. Using your example above (choosing a 1-D linear "stripe" of pixels 
	across the sky), we have the relationship between "pixel no" and internal
	index:

index         0   1   2   3    4   5 .. N
pixel no  10 11 12 13 14 15 .. M

	where the "pixel no" values aren't stored, but may be generated by the linear
	algorithm : "1*x + 10" which is recorded in the "pixel no" quantity which has
	dependence on "index". The Ra, Dec values would be derived by a mapping 
	between the pixel no and Ra, Dec "quantity sets" which is a different algorithm, so 
	that {pixel no} <=> {Ra,Dec}. The 2 algorithms, one for index to pixel no and
	the other, a mapping between frames, are required. The only "stored" data
	would be the size of the 1-D array. Thus, its possible to get

	{Ra1, Dec1 } <=> {PixelNo1} <=> {i}

	where the "bridge" between the Ra,Dec and PixelNo sets is from a mapping/frame
	transform and the second one is from mapping algorithm converting the internal
	index to pixel no values.

	Hope thats clear explanation. Having a choice between storing the mapping in 
	an algorithm that creates the values of a quantity vs. having the algorithm in a 
	full-on transform object may seem a bit untidy. I guess I see a need for 2 different
	methods because the difference is that you dont need a full-on coordinate transform 
	to go from internal index to value because its always a one-to-one conversion 
	(one index always converts to a single value) whereas the frame conversion may 
	change from one *set* of values to another set (of one or more values) as in 
	{RA,DEC} <=> {PixelNo}. 

	I guess I could  be persuded that its "formally" best to have only one way to 
	convert numbers, and create a "simple" frame conversion class for the index
	to value mappings.  I would just hope the implementation of the simple frame 
	transform is "light" so that there isnt any extraneous meta-data to bulk up the
	quantity being passed round/stored.

	Regards,

	-b.t.

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

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