Decomposition (Was: Re: Philosophy of basic Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5

Brian Thomas brian.thomas at gsfc.nasa.gov
Tue May 11 10:59:30 PDT 2004


	David,

On Tuesday 11 May 2004 12:07 pm, David Berry wrote:
> I'm a bit confused by Brian's approach though. Are you saying, Brian,
> that software which cannot handle multi-valued Quantities could simply
> take a multi-valued StdQ and process it as a single valued Q, *without any
> change*? I can see, possibly, that such an approach could give you access
> to the first element of the multi-valued Q, but how can it give
> sequential access to all elements? Is this what you are suggesting?

	Sure, I think you can downcast to the basic Quantity interface, but then,
	you don't have getValue(location) method anymore, and can only retrieve
	the first value in the higher dimensional quantity. Its not particularly
	useful for that use-case.

	What I am suggesting is that the higher dimensional Q's (core, standard) 
	be allowed to be "decomposed" into a set of basic Q's which hold the equivalent
	information. In code, this looks like :

	List decomposedBasicQList = standardQ.decompose();

	In terms of the equivalence principle in the meta-data/data, it is best
	explained via example. Take a standard Quantity with a coordinate
	description, say Counts(x_pixel) ("counts as a function of x_pixel quantity):

	<quantity name="counts">
		<metaData>
			<quantity name="obs time"><units>hr</units><string/><value>3:00</value></quantity>
		<axes>
			<quantity name="x_pixel"><units>pixel</units><integer width="1"/><values>0 1 2</values></quantity>
		</axes>
		<units>cnts</units>
		<float width="4" precision="1"/>
		<values>10.2 39.8 40.5</values>
	</quantity>

	has the equivalent description in basic Q's (abbreviated the node name to "bq") as:

	<!-- the first pixel as bq -->
	<bq name="counts">
		<metaData>
			<bq name="obs time"><units>hr</units><string/><value>3:00</value></bq>
			<bq name="x_pixel"><units>pixel</units><integer width="1"/><value>0</value></quantity>
		</metaData>
		<units>cnts</units>
		<float width="4" precision="1"/>
		<value>10.2</value>
	</bq>

	<!-- the second pixel as bq -->
	<bq name="counts">
		<metaData>
			<bq name="obs time"><units>hr</units><string/><value>3:00</value></bq>
			<bq name="x_pixel"><units>pixel</units><integer width="1"/><value>1</value></quantity>
		</metaData>
		<units>cnts</units>
		<float width="4" precision="1"/>
		<value>39.8</value>
	</bq>

	<!-- the last pixel as bq -->
	<bq name="counts">
		<metaData>
			<bq name="obs time"><units>hr</units><string/><value>3:00</value></bq>
			<bq name="x_pixel"><units>pixel</units><integer width="1"/><value>2</value></quantity>
		</metaData>
		<units>cnts</units>
		<float width="4" precision="1"/>
		<value>40.5</value>
	</bq>

	As you can see, all the information is preserved. We move the "coordinate" info to be meta-data
	about the counts, splitting it up and pairing its value with a particular count rate as 3 basic Q's.
	Its not as compact as the standard Q (which is a reason for why the standard Q exists) but it
	is more searchable, and conforms to the basic quantity in terms of how the data is held.

	=b.t.

---

  * 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] 




More information about the dm mailing list