[QUANTITY] Quantity "arguments" (was [TRANSFORM] What is a "frame"?)
Brian Thomas
brian.thomas at gsfc.nasa.gov
Fri Nov 7 09:00:53 PST 2003
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
More information about the dm
mailing list