Vector-valued Quantities

[Brian Thomas]

On Thursday 13 May 2004 10:27 am, David Berry wrote:
> Ed,
>
> >     Next we want to combine quantities, but we want to do this keeping
> > some relationship between the index values of both quantities.  This is
> > commonly the case when the nth element in each quantity refer to the
> > same object.  QuantitySet provides for a standard way to get your ducks
> > in a row.
>
> 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.
	E.g.

	StandardQ extends Frame {
		values v = new Mapping ();
	}

	where 

	Frame {
		CoordSystem sys;
		List axes;
	}

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

	[And yes Im talking interfaces in the above, not declaring classes, but thats the
	notation that David was using so I picked it up]

>
>    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.
	This model, either way, is inconsistent with the interfaces.

> [sniped]

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

	b.t.

>
> David

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]