A plehtora of Quantities

[Guy Rixon]

Ed,

I agree with the first parts of your analysis but I think you're stretching
things when you say that an SED _is_ a quantity (list), intuitively.

An SED is a list of flux-frequency-bandwidth tuples, where each element of
each tuple is a quantity (i.e. has value, unit, accuracy).  No way is each
point as a whole "a quantity" in normal scientific usage. Furthermore, in a
composite SED, each quantity of each point can have _different_ units. I.e.,
there's nothing to share between adjacent quantities; therefore, no motivation
to make internal parts of a quantity list-valued.

This list-valued thing is what breaks Q for me.  I would like to see the Q's
inside the list, not the list inside the Q. _That's_ intuitive, and it also
means the listing structure can express the relationship between the Q's; the
standard Q structures don't have to deal with relationship.

Is the real reason for the list values inside the Q is to save space in the
XML representation?  I don't buy this.  If we need to save space then we
shouldn't be using XML.  Or is it to try and map a Q to things like image
rasters? In that case, the system is compromised from the start and it
would be better to have different, cleaner structures for the XML case.

Cheers,
Guy


On Thu, 13 May 2004, Ed Shaya wrote:

> Martin,
>
>     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
> parts.
>     The whole thing is intuitively obvious.  N'est pas?
>
> Ed
>
>
> 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
> > Distribution.
> >
> > 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?
> >
> >
> >
> >
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523