[QUANTITY] The quandary

[Steve Lowe]

All,

I've attached a draft of a document Data Models for Spectra: 
Abstractions for Quantities and Coordinates (4 pages---there's an 
extraneous blank page at the end) that was intended for distribution at 
the Cambridge (UK) Interop meeting, but was held up by e-mail problems.

I think I can summarize our view on the Quantity quandary in a couple of 
points, which are in agreement with some of the points made by others on 
this thread:
1) The "units" that we all learned about in high school form just one 
part of the story. A coordinate system is needed, which may itself be 
specified in several parts (reference system, reference frame). And the 
property for which a value is being specified needs to be identified so 
that you can know what other quantities are equivalent to it (e.g., 
wavelength of light in vacuum corresponds to a definite frequency.) This 
leads to a new object, a Representation, which subsumes units, 
coordinate system and property identity, essentially by listing them. In 
actual applications, the Representation employed could be as simple or 
as complex as needed---for example, a plotting program might only need 
to know the "units" component of the representation to label the plot, 
but a multiband spectral energy distribution program might need to know 
that the value is actually a wavelength of light that can be converted 
to a frequency.
2) Representations provide two pieces of information: names for things 
like units, coordinate systems and properties; and the information 
needed to transform between numerical values for the same quantity 
expressed in different representations.

Note that even if there are a large number of values (say, a big table 
of wavelengths/frequencies/photon energies), the Representation object 
doesn't have to be duplicated for each value. There just has to be one 
for each distinct Representation list (wavelength/Angstroms, 
wavelength/meter, frequency/Hz,...), and each Quantity object has a 
pointer to the one it uses. Thus, the storage overhead need be no 
greater than storing just units.

Note also in the document that we're not proposing a static 
programming-language class hierarchy for all physical properties, but a 
small set of classes for which physical properties will be class 
instances having a structure defined by some sort of "map" data file.

As for attaching values for resolution/pixel size etc., I think these 
also should be considered to be richer objects for which the simplest 
cases (the ones usually used) are parameterized by a single number. In 
general these are properties or parameters of a more general observation 
or measurement model. Similar to the way Quantities are handled, a 
general framework can be devised that for which the one-parameter 
"standard" cases can be implemented without excessive overhead. We're 
working on that.

Steve


-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe at cfa.harvard.edu
1-617-496-1661


-------------- next part --------------
A non-text attachment was scrubbed...
Name: DataModelQuantity.pdf
Type: application/pdf
Size: 108339 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20030521/2a2cccff/attachment-0001.pdf>