# [QUANTITY] Review of Quantity suggestions

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Tue Jul 22 12:17:02 PDT 2003

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