A plehtora of Quantities

[martin hill]

Jonathon has almost succesfully diverted me from this debate, which if we're 
returning to the beginning is in danger of going circular.

Quoting Ed Shaya <Edward.J.Shaya.1 at gsfc.nasa.gov>:

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

I understand the concept and the starting point.  I just don't see a case for 
defining a new 'type' that all things must derive from. I can see a case for 
a 'Measure' but even that is a bit high.  For example, are there any 
programming languages that define such things?  No - they give you the 
components to assemble your own structures, because building root types like 
this hinder later.

It's the 'experimental science' and 'most' that are enough to make me want to 
avoid an 'Everything' object.  What about same-unit ratios (eg ellipse 
characteristics)?  Heirarchical Triangular Mesh? Enumerations? pi?

> Since a list of one 
> is still a list then we can temporarily combine both sides of the OR.  

This is trueish, but I'm not keen on forcing people to deal with 'int[0]' 
when 'int' is what they mean and want.  We lose typing information.

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

So now we have to make sure that Quantity can handle equations too?!  Consider 
an SED constructed from a number of combined passbands... The work to model 
this belongs with modelling SEDs...

> You can create any Quantity subtype by making restrictions to the 
> StandardQuantity and thereby carve exactly the component that you need.  

Hmmm that's not really the 'restrict' meaning I normally associate with 
subtyping! It's not the way most software languages define it; few have 
facilities to 'hide' methods on supertypes. 

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

Yes, and I understand the reasoning behind it.  Being intuitvely obvious 
however doesn't mean it will be good for us...

I like the Quantity concept as a basis for discussion, but using it in our 
actual object models is going to make it harder, not easier, to interoperate 
and build models.  

Cheers,

Martin


-- 
Martin Hill
07901 55 24 66
www.mchill.net