Vector-valued Quantities

[David Berry]

Brian,

> > Given that a CoreQ consists of a Frame and a Mapping (taking a
> > ValuesList to be a special form of Mapping), it is represented by:
>
> At the risk of delving into an issue with no bottom..
>
> Well, thats not how I see it. A CoreQ has coordSys information, but
> if you want the full "Frame" you must use StandardQ, which has axes.

Not clear what you see as the distinction between a CoordSys, and a Frame.
I thought a Frame is supposed to be a container for all the meta-data
needed to describe the system in which the phenomenon values are recorded.
So how can CoreQ do without a Frame? Admitedly, the current doc has CoreQ
*inheriting* from Frame (via BasicQ) and so CoreQ *is a* "full Frame". The
more I think about this the less I like it - CoreQ should aggregate a
Frame, not inherit from Frame.


> E.g.
>
> 	StandardQ extends Frame {
> 		values v = new Mapping ();
> 	}

As above, I do not like Quantity (of any class) extending Frame, Frame
should be component structure which is aggregated by Quantity.

> 	Frame {
> 		CoordSystem sys;
> 		List axes;
> 	}
>

Looks OK, depending on what the data type of the elements of the "axes"
List are. I hope they are not Quantities of any form, since a Frame is
supposed to be a *description* of a coordinate system, such as "FK5
J2000", and is not supposed to hold or represent any values, whereas
Quantities *are* supposed to represent values >within some Frame<.

> This alone shows the problem in having BasicQ and CoreQ interfaces
> inherit from "Frame". The inheritance hierarchy (for the interfaces)
> should probably be
>
> Component -> BasicQ -> CoreQ  -> StandardQ
>
> with an interface called "Frame" that looks like the one above, (and only
> StandardQ =or= CompositeQuantity impliments it) and a "component"
> interface which has:
>
> 	Component {
> 		units u;
> 		dataType d;
> 		CoordSystem s;
> 	}
>

What is wrong with the idea of having a separate Frame class, a separate
CoreQ class and a separate StdQ class - why have any inheritance?

> >
> >    CoreQ {
> >       Frame f;
> >       Mapping m;
> >    }
> >
>
> If this is meant to be an interface, it is incorrect. If it is a class, then
> there are no access to the axes in the CoreQ (only StandardQ or Frame
> gives that) and it looks a hellava lot like a StandardQ to me (it has
> axis description). So again no on both counts.


But Brian - the Model "CoreQ = Frame + Mapping" is what we have been
working with ever since the Baltimore meeting! The opening sentence of sec
6.2.3 says "CoreQuanity is a Frame which can return a finite set of values
and accuracies..." - the values are returned by the Mapping. This makes
the point that "CoreQ = Frame + Mapping" pretty clearly to me. My only
problem with this sentence is that I would prefer it to be "CoreQuantity
has a Frame and a Mapping, which can return a finite set of values..."
("is a" -> "has a").

The Frame in the model "CoreQ = Frame + Mapping" describes the *values* of
the Quantity, not the "positions" of the elements within the Quantity
(which is the job of the aggregated CoreQ's within StdQ).


> 	This model, either way, is inconsistent with the interfaces.

Only in so far as the current interface says that CoreQ *is a" Frame
whereas the above model suggests that CoreQ "has a" Frame. Can you point
out any other inconsistencies?


> Let's say we have two scalar-valued CoreQ's:
> >
> >    CoreQ flux
> >    CoreQ wavelength;
> >
> > If we then want to combine these into a single vector-valued CoreQ, do
> > we not just join the two Frames together to form a compound Frame,
> > and then joing the two Mappings together to form a compound (parallel)
> > Mapping, and then combined them in a new CoreQ as follows:
> >
> >    CoreQ SED {
> >       CompoundFrame {
> >          flux.f
> >          wavelength.f
> >       }
> >       ParallelMapping {
> >          flux.m
> >          wavelength.m
> >       }
> >    }
> >
> > The above *is* a CoreQ since it is made up of a Frame and a Mapping, so
> > why do we need a new "QuantitySet" class?
>
> Quantity set aggregates quantities rather than numbers or strings which is
> what mappings work on. You yourself said that the Mappings DON'T take
> as input Q's (or output Q's).

I did indeed. The ParallelMapping in the above is used to transform
numbers, not Quantities. I thought that was obvious. Using the model
"CoreQ = Frame + Mapping", the above structure *is* a CoreQ - it has a
Frame (a CompoundFrame) and a Mapping (a ParallelMapping). The Frame
describes 2 axes (flux, and wavelength) and the Mapping generates two
output values (flux and wavelength). So it *is* a CoreQ. Again, why do we
need a new QuantitySet class?


David