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

[Ed Shaya]

Dave,
I was starting to answer your previous message, but this one seems more 
basic, so I will answer this
one first.


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). Pixel index is the only
>indepedant variable we have when considering access to a collection of
>stored data values. 
>
This is an interesting perspective. The term pixel only applies to CCD 
output, so you must not really
mean pixel at all but rather index number. And, I can't disagree with 
the statement that all data, in computer memory is retrieved by an 
address determined by the index value of the array. But,
you may be familiar with the concept of a hash table. In a hash one 
addresses an array not by
its index number but by a key-value pair. So one may have a list of 
employees and information about
them. Rather than searching down this array of information for a 
particular employees name one
creates a link between the name and the index value. So now one can ask 
for table.address("Jay")
or table.salary("Mary"). This is much more convenient because the index 
value has no intrinsic
meaning but the name does. In our quantity model, if the axes are 
cartesian then one gives a physically
significant name to each column and to each row. If it is not cartesian 
then one may need to give
a name to each pixel. One may choose to not actually create these hash 
tables, but keep them as
virtual concepts that one calculates. But often enough, it actually is 
faster and better to really populate
them. For images we can name the pixels by their RA,DE pair and for 
spectra we can name pixels by
their corresponding wavelength and/or frequency. Now it may be that an 
"image" is actually stored
as a table with rows RA, DE, Flux and there are no pixels. In this data 
model both could be described
the same way, once one deduced the meaning of the table that the Flux 
depends on RA and DE. Operations between them would be easier.