[QUANTITY] The quandary

[Arnold Rots]

The most important statement is that Quantity, as Ray presented it, is
an immensely useful concept.  You will find it in a number of
incarnations (i.e., the coordinate types) in the Space-Time Coordinate
schemas.

Having said that, I need to point out that it becomes very quickly
very complicated, as I experienced.  And here is why.

I think there are three requirements that we need to leverage on the
Quantity class:

1. A Quantity object consists of a Name and one or more (related)
components from a finite list that includes:
- Value
- Error
- Resolution
- Size
- PixelSize
(Not all components have meaning for all kinds of Quantities and
especially the last three components in this list are probably only
there because they are convenient for coordinate Quantities; we can
worry later about what is and what isn't on this list - it's not
terribly important at this time)

2. Each component has a separate Unit attribute that is of appropriate
type (length, angle, time, flux density, etc.), where each type
consists of an enumerated list (e.g., for time: s, d, a, yr, century).
(This may seem overkill, but it is essential: there are too many
catalogs that have, for instance, positions in degrees and errors in
arcsec; or a time in ISO8601 format (no unit!) may have resolution in
seconds)
(There may actually be reason to add a second Unit attribute, in the
case of velocities - i.e., one for length or angle and one for time -
unless one is prepared to enumerate tediously all possible
combinations)

3. Internal consistency should be enforced in each Quantity object
(If an angle is specified in sexagesimal format, the error should
really be a double and its Unit should be an angle unit; if the Value
is a vector, the error should be defined in 2-D; if the Value is a
vector, there should be (1 to <vector-length>) units; etc.)
(What this really amounts to is that the data types and the units need
to be consistent among the components of a Quantity)


The rub is really in the last requirement:
You would like to define the base Quantity class as a Name and one or
more components, where each component holds an object of some data
type with one (or more) Unit attributes.  And when you derive a
particular Quantity type, you would like to allow only specific
combinations of component data types and Units.  But that means that
the only thing you can really specify in the base class is the Name -
while the structure needs to be spelled out for each subclass.
That is unsatisfactory.

For example:
Quantity holds three objects:
Name, one object of class Value, and one object of class Error

>From Quantity we derive QTime, QLength, and QPos2vect
>From Value we derive VTime, VLength, and VPos2Vect
>From Error we derive ErrTime, ErrLength, and ErrPos2Vect

VTime may be of type ISO8601, or JD, or MJD, while ErrTime can be a
double with Unit of type timeUnitType.
VPos2Vect holds two doubles, with angle or length unit, while
ErrPos2Vect may be two doubles, or something (three doubles or a
matrix) that defines an error ellipse, with appropriate units.

QTime holds: Name, VTime, ErrTime
QLength holds: Name, VLength, ErrLength
QPos2Vect holds: Name, VPos2Vect, ErrPos2Vect

But we don't want to allow:
QTime consisting of Name, VLength (angle Unit), ErrPos2Vect (time Unit)
because it does not make sense.

However, that means that VTime and ErrTime need to be specified in the
definition of QTime.  And that, in turn, means that the only common
thing that can be put into Quantity is Name.  This is precisely the
way it is in the STC schema (and the reasons are what I described above).
Value and Error base classes can be added to the base class Quantity,
but they would be pretty meaningless.

One could, of course relax the requirements (especially the third
one), but I am not so sure Quantity will then remain as helpful as we
hoped it would.

  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------