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

[David Berry]

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. 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. On the sky, it is true that flux is a function of
(RA,Dec), but we do not have "the sky" in our data, we have a collection
of pixels, and so flux is simply a function of which pixel you are looking
at. So why do we need the complications of allowing Quantites to have
other Quantities as "arguments"?

The model you present seems to be saying that an axis "is a" Quantity. I
cannot see an axis as a Quantity - I could see it as a "Thing", but not as
a "Quantity". A Quantity is basically one or more numerical values, and an
axis is not a numerical quantity. Saying that an axis is a Quantity is
rather like saying that a tape measure is a distance. You *use* an axis to
describe a quantity, but the axis itself is not a Quantity. There is a
distinction between as axis, and a set of axis *values*, and you do not
need to store axis values within a quantity because they are always
implied by the pixel indices. So having axis values in there just adds
unnecessary complexity.

Please tell me if (and how) I am mis-understanding your model.

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.


David




/* Flux as a function of RA,DE or GL,GB positions */
FluxQ
  Argument
     positionQRef /* The Axes are described by this Argument.
                    * We chose to use a ref for clarity. */
  ValueList
     list of flux values /* All of the Flux numbers */
  Units
       ergs/s/cm2/A

PositionQ /* A two dimensional position */
  Argument
     Index(NAxis1) /* Index is an object that simply
                     * generates the numbers 0,1... N-1 */
             name
                 "i-axis"
  Argument
     Index(NAxis2)
             name
                 "j-axis"
  DataFormat
     tuple /* Values of positionQ are (i-axis,j-axis) pairs
           int
           int
  ValueList
        0,0 0,1 0,2 ...
        1,0 1,1 1,2 ...
           ...
  Mapping
/*Mapping always maps ValueList numbers to new numbers.
 *Arguments are untouched, but new units may be part of output.
 *Generally, the errors need to be remapped too, but pixel numbers
 *don't have errors, hopefully. */
     PixeltoCoordsAlgorithm
       algorithmID
       /*Provides unique identification of algorithm to use.
        *Perhaps the code could actually be at this URL */
             "http://ivoa.net/algorithms/WCS/position/pixelToCoords.c"
           Inputs
           /* These are parameters of the Algorithm.
            *Each algorithm has its own requirements
            *on the number of Inputs, their type, and the order.
            *In this case, they happen to specify the output frame.*/
              Frame1
                Equinox
                ReferenceSystem
              CenterPixel
                 445 420
              CenterRADE
              PixelsPerArcsec
              OutputUnits
              /* The algorithm also needs to know the output units */
                (hour min sec)
                (degree arcmin)
  Mapping
/*An alternate mapping to Galactic coordinates. It differs only in
 *the input values because I assumed that the algorithm knows
 *how to handle both coordinate systems*/
     PixeltoCoordsAlgorithm
        algorithmID
             http://ivoa.net/algorithms/WCS/position/pixelToCoords.c
           Inputs
              AlternateFrame2
                 Equinox
                   "1900"
                 ReferenceSystem
                   "GalacticII"
              CenterGlGb
              CenterPixel
                  445 420
              PixelsPerArcsec
              OutputUnits
                   degree
                   degree

Ed


----------------------------------------------------------------------
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