[QUANTITY] Quantity "arguments" (was [TRANSFORM] What is a "frame"?)
David Berry
dsb at ast.man.ac.uk
Mon Nov 10 02:52:02 PST 2003
Brian,
> Before I get started, to use your terms, I think you mean "list index"
> instead of "pixel index".
Sorry, pixel probably isn't technically the right term, but it's a nice
noun describing something which has a position and a value. Maybe a
"datel" (data element) would be better...
> > 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've no problem with the idea that you can use a quantity to store a
collection of (RA,Dec) value. My comment is that a Quantity holding flux
is *primarily* a function of list index, and is only indirectly a function
of (RA,Dec), and so a Quantity which includes a primary description in
terms of (RA,Dec) rather than list index could be seen as misleading.
> 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.
I have no problems with the idea that a Quantity can be used to store a
set of pixel numbers - ideally a Quantity should be able to store values
for *anything* which can be expressed numerically. That is, my point is
not about what sort of data can be stored in a Quantity, but about the
use of nested Quantities and the nature of "arguments".
[Just as an aside, in the "alternative model" I outlined in my previous
message, the situation you describe above of "i" and "PixelNo" would be
handled by making "i" the "base Frame" in the WCS FrameSet (i.e. the Frame
describing the coordinate system in which the data structure is actually
accessed), and having another Frame in the FrameSet labelled "PixelNo"
which would be connected to the base Frame by a "ShiftMap" (a subclass of
Mapping which simply adds a constant value - in this case "10" - onto each
axis value).]
Using a Quantity to define an axis within another Quantity is potentially
confusing because it seems to me to be using a single class to perform at
least two distinctly different functions... The purpose of a Quantity is
to store a collection of numerical values. Thus using a nested Quantity
to describe WCS is suggesting that the WCS "is a" set of numerical values,
which in my mind is quite a limiting view of WCS. My view of a WCS is that
it is a collection of recipes for converting any position given in one
coordinate system into another related coordinate system. That is, it
just defines the recipes and the coordinate system descriptions, but does
not itself encapsulate or represent any specific set of numerical axis
values, and so is not a Quantity in any real sense.
Now you may say that this is being picky because the list indices define
a set of axis values and so there is always an implicit set of numerical
axis values. But I think it is important to distiguish between the
abstract WCS as I have described it above, and the *use* of that WCS to
transform a set of values. One reason for this is that there are cases
where you are interested in positions which do not correspond to an exact
list index. For instance an algorithm to draw an annotated coordinate
grid typically explores "pixel space" down to an arbitrary fraction of a
pixel.
> 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.
I would agree with all this, except that as noted above I'm not happy with
equating the concept of an "axis" with a set of numerical values, because
it seems to imply restrictions on the values the axis can take. But I
agree with the point that PixelNo and "i" are equally valid coordinate
systems for accessing the data. In practice, if the client is interested
in accessing a data value at a given position in some arbitrary coordinate
system, then the supplied position would first be transformed into the "i"
system using the Mappings in the WCS component, and the resulting indices
would be used to get the required value out of the data structure
(possibly using some form of interpolation if the resulting list index was
non-integer). But I'm not sure that the summary you give above
demonstrates a need for argument Quantities.
> > 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.
I agree that there is a requirement for each axis to be described, but I
suspect using another Quantity to hold that description is confusing
because it seems to equate "an axis" with "a set of numerical values".
> 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.
Absolutely agree. We have developed reasonably sophisticated algorithms
in AST for this sort of thing. For instance, if you have two data sets,
each with an associated arbitrary WCS FrameSet, we have an algorithm (see
http://www.starlink.rl.ac.uk/star/docs/sun211.htx/node119.html) which
will search the two FrameSets for a common Frame and will return a Mapping
which transforms pixel coordinates in the first data set into the
corresponding pixel coordinates in the second. One of the primary
motivations for the development of AST was to enable this sort of searching
and data fusion.
> This is done as have argued above, and makes one quantity appear to
> supply the axes values for another (and vice versa).
I think a summary of my position is that a WCS should not include a set of
axis *values*, either implied or explicit, and therefore using a Quantity
to store the WCS is misleading.
David
----------------------------------------------------------------------
Dr David S. Berry (dsb at ast.man.ac.uk)
STARLINK project Centre for Astrophysics
(http://www.starlink.ac.uk/) University of Central Lancashire
Rutherford Appleton Laboratory PRESTON
DIDCOT United Kingdom
United Kingdom PR1 2HE
OX11 0QX
More information about the dm
mailing list