[QUANTITY] Quantity "arguments"

[David Berry]

Ed,

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

I'm not sure I am completely following your argument here. Are you saying
that in your model axis values are stored in a Look-Up-Table - a 1-D LUT
for each axis if the axes are independent, and a single N-D LUT otherwise?

In which case, how do you find the coordinates associated with a
non-integer pixel positions? As I mentioned to Brian, one place where you
need to do this is when plotting a coordinate grid, but there are others.
Just doing interpolation in your LUT may often be a poor solution (e.g.
when plotting a coordinate grid for an image obtained with a highly
non-linear projection). Also, storage requirements for a 2d image would
be tripled if you store the (RA,Dec) coordinates of every pixel
explicitly.

Sometimes (as in the catalogue case you mentioned in your message) there
may be no underlying continuous "projection" from "pixel" indices to
"WCS" coordinates. In these cases you have no option but to use a LUT,
maybe allowing interpolation. But this is a special case and shouldn't be
used as the basis for the whole model. A base Mapping model which describes
continuous relationships coordinates can be subclassed to describe a
discrete LUT (see the AST "LutMap" class for instance). Such a Mapping
may be used within a FrameSet to connnect a 1D Frame representing "row
number" to a 2D Frame representing (say) (RA,Dec). Fractional row numbers
could be handled either by converting them to the nearest integers before
accessing the LUT, or by performing some form of interpolation in the LUT.

I would say that a WCS should always describe the algorithm, rather
than storing actual numerical values (unless this is required by virtue of
there being no "projection algorithm" in the general sense, as would be
the case for a random list of values). Some of the benefits of storing an
algorithm description rather than a set of numerical values are:

1) Usually takes up much less space
2) More accurate (i.e. you do not need to use interpolation for
non-integer list indices)
3) Provides more functionality (for instance, you can analyse the
algorithm in various ways, e.g. to see if it can be represented as a
FITS-WCS recipe).

I would prefer to see WCS modelled as "a set of algorithms [which may need
to refer to numerical values]" (i.e. a FrameSet) rather than as "a set of
numerical values [which may be represented by an algorithm]" (i.e. a
Quantity).


By the way - you, Brian and I seem to have talked everyone else out of
this discussion! Is anyone else still following these threads?


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