[QUANTITY] Justification for Matrix Quantities (Was: Re: [QUANTITY] Requirements and apology)

[Brian Thomas]

On Thursday 30 October 2003 03:00 pm, Ray Plante wrote:
> On Thu, 30 Oct 2003, Brian Thomas wrote:
> > What about a quantity that has dependence on another one. Consider
> > the search use-case that an astronomer is looking for all flux
> > measurements of the visual band. Of course, the search should find those
> > "atomic" quantities that are V-band fluxes, but it should *also* beable
> > to find fluxes from other flux quantities which are described in terms of
> > wavelength (e.g. F(lambda) ) and  where some part of their wavelength
> > range overlaps the visual band (300-700 nm). For these quantities F(l)=>
> > F(300-700nm) == F.
>
> One way to look at this use case is to say that the fluxes you are looking
> for are not "Quantities" per se but rather a higher level concept that
> perhaps derives from "Measurement" which can include the observed
> frequency.  The "Flux" contains a quantity that can hold the actual
> flux value; it also holds the quantity representing the frequency.  
>
> The point here is that the dependency between these quantities is captured
> at a higher level.  It is not necessary to encapsulate them both within
> this simple thing we call "Quantity".  

	Ray, all,

	But I still think it _is_ important and, in the end, we will find that "quantity",
	in order to be usefull, is not that trivially simple. Let me try to argue this from another
	perspective: transforms/mappings, which, if Ive got this right, is something
	which everyone believes that every quantity will have a pointer/hook for
	(*or* in "measurement", which I know many of you define as something similar
	to "my" quantity. so in the next para substitue "measurement" for "quantity"
	if you think that way).

	The transform will have to "know" about the indices/axes of any matrix
	quantity that exists. As many desire there to be a "hook" (pointer) to 
	the relevant transform, this again, implies to me that the quantity contains
	enough meta-data (e.g. axes values, units, etc) to allow the transform to work. 

	Its not enough to just say that we want the transform to operate only on matrixes 
	(e.g. multi-dimensional things where the axes are labeled only by unitless, errorless 
	whole numbers) as that is fairly limiting on the transform interface. IF you go that
	route, then we have to create 2 different general (abstract classes/interfaces) 
	types of transform,  one for linear algebra operations only, the other for full mappings.
	 Even if this sounds philosophically nice (it doesnt to me) its a problem to cleanly 
	implement.


	Regards,


	=b.t.



-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128