[QUANTITY] Review of Quantity suggestions

[Patrick Dowler]

Having now actually read the paper, I have a few comments.

My gut instinct for Quantity is that at the core it is about dimensioned 
values; thus the simplest view is that it is a value and some units:
6 feet, 20km/hour, 45 minutes, etc. Even the concept of error is
opional. One thing to consider is that observational science has (or 
at least should have :-) errors assocaited with all quantities, but this is
not strictly true of theory. With theory (simulations) one likely has 
systematic errors but not random errors (unless there are some empirical 
inputs with errors that matter, but I haven't seen that sort of thing 
advertised in the literature - please correct me if I'm wrong on this one).

First, it appears that we are currently only talking about the value as a 
primitive type (int, real, ...). This makes the construction and use of 
composite types (interval, point, polygon, ...) potentially complicated,
but see below for some example uses. Also, the "data" seems to
be array-based, which is just one (albeit important) type of composite
structure. 

The "interim" model includes things like name, UCD, and description
that IMO do not belong in the lowest level object at all. many quantities 
will have no sensible values for these things, especially if the idea is to 
build more sophisticated types from two or more quantities. There should be
higher level constructs like Property that collect together a name and a 
quantity.

Here is a really vanilla TextUML class diagram, without types:

Quantity
+value
+units

Measurement extends Quantity
+error

** usage examples (i.e. various "properties" I would like to use) **

* property: 1-d bounds (an interval)

IntervalProperty
+name : "some bounds"
+lower : Quantity (value=1.0, units="abc", error=0.01)
+upper : Quantity (value=2.0, units="abc", eror=0.011) 

Property
+name : "some bounds"
+value: Quantity(value=[1.0,2.0], units="abc", error=0.01)

Property
+name : "some bounds"
+value: Quantity(value=[1.0,2.0], units="abc", error=[0.01,0.011])

In the second & third examples, the value of the Quantity is a non-primitive 
type (Interval) but you only get one error so it is either incomplete (2) or
starting to be complicated to map errors and values. This is a general
issue with arrays of values (array of Quantity or Quantity where the value and
error are arrays), but I think (2) is generally indesirable and will drop it 
now :-) The downside of (1) is that the composite object is not generic; it 
needs to define the structure of the "value" and one would need several/many
different property types.

* property: position (a Point)
= use: source and object catalogs

PointProperty
+name : "position"
+x : Quantity(value=4, units="m", error=0.1)
+y : Quantity(value=5, units="m", error=0.1)

Property
+name : "position"
+value : Quantity(value=Point(4,5), units="m", error=Ellipse(0.7,0.08,25))

note: error ellipse has args e,a,theta

Here we are see several issues. First, in (1) the errors are un-related while 
in reality the error of a position is better described with an ellipse. With 
(2) we are not specifying the units for the ellipse, suggesting that we do 
need separate value and error units. To further complicate things, the error 
ellipse has three components with different units (dimensionless, "m", and
"degrees" respectively). So, we have the quandry that we would like to use
composite types for value and error within a Quantity (in order to properly
characterise error) but we also need potentially a collection of units for 
these composite types.

* property: shape (an Ellipse)
= use: source and object catalogs

EllipseProperty
+name : "shape"
+ellipticity : Quantity(value=0.7, units="dimensionless", error=0.01)
+semiMajorAxis : Quantity(value=25, units="arcsec", error=0.1)
+positionAngle : Quantity(value=60, units="degrees", error=2)

Property
+name : "position"
+value : Quantity( value=Ellipse(0.7,25,60))                   
                        units=EllipseUnits("dimensionless","arcsec","degrees") 
                        error=EllipseError(0.01,0.1,2) )

Well, as you can see this is starting to get pretty messy :-) With a 
"container" type like ellipse we also need unit and error containers because 
the components are not correlated. Note that this gets much worse if
we had a property like "footprint" with an Ellipse that also stored the 
center (a Point). Then we'd have both the correlated errors of the Point
(an Ellipse) and the uncorrelated errors of the shape of the ellipse.

** summary **

- separate value and error units is probably unavoidable

- composite types made from scalar Quantity(s) break the simplistic but very 
nice view of a Property as a name,value pair because they put the structure
in the Property rather than in the value (ie. the Quantity)

- composite types made from scalar Quantity(s) do not capture the case where 
errors in components are correlated (ie. position errors); it is very 
important to have the right combination of value and error types, so to me 
this makes only having scalar types as the value of a Quantity impossible

- as for the array-based use expressed in Fig 10, I am reminded here of the 
Go4 "composite" pattern where containers and their components are both
of the same type (used to great effect in computer graphics, for example).
It seems to me that if an array of Quantity(s) is also a Quantity then you 
gain some benefits: (i) error in the array is systematic, error in the 
components is random, (ii) units when accessing via the array are homogeneous 
while components could have different but convertible units, and (iii) well, 
there isn't a iii but it just seems to be aesthetic.

- I am working on seeing if using this "composite" pattern can unravel
the examples above into something less complex (ie. basically the idea that a
Quantity can have a scalar or Quantity(s) for a value, but not a container in 
the same sense as an array because the components have different roles or 
meanings).


cheers,

-- 
Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)