A plehtora of Quantities

[David Berry]

Martin,

> So now we have QuantitySet, CoreQuantity, AtomicQuantity, StandardQuantity,
> ListQuantity, CompositeQuantity, etc. So in a familiar whingy ranty voice:
> This is an example of what happens when you and try and find one class
> to rule them all.

I'm with you I that I would have much preferred to avoid overloading the
concept of Quantity so heavily.  I have argued many times in favour of
defining a collection of component structures which do not inherit from
Quantity in *any* sense and which do not *contain* Quantities in any
sense, and then using these as components within a Quantity structure.
I think we were nearly there at one point, in the days when we had a
Quantity structure which looked like:

Quantity {
   FrameSet acs;  (describes axis coordinates - WCS to you ane me)
   FrameSet vcs;  (describes alternate data value systems)
   ValueList values;  (holds the data values in their "raw" state)
   ...
}

Here a FrameSet is as in the AST library - a structure which describes
the inter-relationships between a set of one or more coordinate systems,
by encapsulating a set of Frames connected together by Mappings. And a
ValuesList is a structure which simply contains a N-d array of values,
with methods for getting a value at given array indices.

I've obviously not explained this model in any detail here, but it won
some favour for a while, but then the desire to use different flavours of
Quantity to do everthing took over.


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                                Tel. 01772 893733
                                             01257 273192