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

Brian Thomas brian.thomas at gsfc.nasa.gov
Tue Nov 4 09:21:43 PST 2003

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