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

[Brian Thomas]

On Thursday 30 October 2003 03:00 pm, Ray Plante wrote:
> 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".

	Hi Ray,

	My first response to this is that we shouldnt get hung up on only speaking 
	about a "quantity" package. Even if you feel that dependencies within quantities
	arent "quantity" they are still "basic" parts that will be re-used and shared over 
	and over by the component level stuff (e.g. "instrument", "coverage", etc). 

	There are other packages that are needed at the base level, we have already
	 mentioned the need for possible separate packages to handle interfaces of 
	"mapping/transform", "errors", system of units, etc. and the case  can be 
	made for  "measurement" (as you refer to it) as well.

	But back to the core issue: Why is a quantity dependent on another quantity still a 
	quantity? (heh) Because it makes a difference to the analysis of the units. F(l) will have 
	different units than "F" until it is evaluated in terms of some wavelength range. As a 
	result, this complexity in the dimension of the units needs to be captured, coordinated 
	within that quantity so that when the evaluation occurs, it is appropriately treated.
	Hence, I deduce that the "measurement" you describe is still "quantity".

	Regards,

	-b.t.
 

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

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