A plehtora of Quantities

[Ed Shaya]

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?
>
>
>
>