A plehtora of Quantities
Edward.J.Shaya.1 at gsfc.nasa.gov
Thu May 13 06:37:24 PDT 2004
Let me return to the beginning of this thread and really start from
the beginning, again (as I see it, of course). In any experimental
science most of the data and the info on the data are composed of
quantities which consist of (or should consist of) a value, a physical
unit, and an accuracy OR a list of these things. Since a list of one
is still a list then we can temporarily combine both sides of the OR.
But, if we have a list then we also need to provide information on what
is changing with index value. Are we jumping from one object to another
or from one wavelength to another? Therefore, the index becomes an axis
with a quantity associated with it, so one can give accuracy and units
on those values as well. An example would be an SED which is composed
of fluxes with units and errors and with each flux is an associated
wavelength which has units and an error or bin size (actually both,
since there is an error in the central location of the bin (and
additionally there is an error in the bin size). So we start off with a
StandardQuantity which allows for such things in a standardized way.
You can create any Quantity subtype by making restrictions to the
StandardQuantity and thereby carve exactly the component that you need.
Want a quantity with errors but no units? Go right ahead. And by the
way, if you want some shortcuts to commonly used restrictions there is
AtomicQuantity. ListQuantity and CoreQuantity to help you along. Use
them if you want or don't.
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.
And SED is a Quantity, but you are free to create more complex
things using Quantity and QuantitySet that are not themselves Quantities
(like Observation or STC). The intent was to make the more complex
things easier to design by allowing use of these two powerful component
The whole thing is intuitively obvious. N'est pas?
Martin Hill wrote:
> So now we have QuantitySet, CoreQuantity, AtomicQuantity,
> StandardQuantity, ListQuantity, CompositeQuantity, etc. So in a
> familiar whingy ranty voice: This is an example of what happens when
> you and try and find one class to rule them all. We now (appear to)
> have a set of Quantity classes that we can 'pick' from to create our
> new objects (such as Passband) - and if we can't find an exactly
> suitable one we just have to get something close. We can't model
> exactly what we want.
> Perhaps a simple example would help to sort this out. How would we,
> for example, model a SED?
> A first stab would be to define a Passband interface that has methods
> something like getMinWavelength(), getMaxWavelength() and
> getLimit(wavelength), the last of which returns some proportion of
> passed flux given a wavelength. (There is more, but this is just an
> example). Then we have SimplePassband (which is just a wavelength
> range with a flat top), a FormulaPassband (which has a formalae behind
> it describing the shape of the passband), a GraphPassband (which has a
> set of points behind it describing the shape of the passband), and we
> can create standard instances of these for standard filters. This
> gives us a Passband model that is easy to implement (for simple
> passbands) and we can plug into other models with no fuss, as we just
> need to include the Passband interface definition.
> We can have an abstract Wave object, with both getFrequency() and
> getWavelength(), implemented by Wavelength and Frequency which have
> Accuracy, UCD and can return each other suitably inverted.
> So now we can create a Flux object (or interface?) that has a Passband
> and a total energy - perhaps subclasses might include Magnitude that
> can handle magnitudes as well as returning estimated energy values.
> A list of Flux objects along with a coordinate is a Spectral Energy
> These are reasonably simple to build using the components included as
> part of the Quantity concept. But they are much easier to build and
> adapt by themselves without having to be Quantitys themselves. For
> example, it might be useful to have Passband implement Accuracy
> (though I am probably showing my astronomical ignorance here) as I
> understand they often act as the error on a flux.
> How would this work with the Quantity philosophy?
More information about the dm