[QUANTITY] Why quantities always have errors (Was: Re: [QUANTIT] Use-cases, role in larger scheme)

[David Berry]

Martin,

> I think we're back to the sources of values not the values (and perhaps
> the cross-purposes of our discussion).  You can simulate a star, and you
> will get a flux (I presume without an error unless you're simulating a
> sample of stars or you're building errors in specifically?).  Or you can
> observe a star, and get a flux.  Both fluxes are the same 'type' and you
> can compare fluxes.  You can't compare the position of the star with the
> simulated flux, and there should be *no way* of representing such a
> comparison in our data models without some big flag coming up and
> hitting the developer over the head.  Nor can you compare measured flux
> and measured position.  You should not be able to cut and paste a flux
> into a position plot.  You will want to be able to serialise both - but
> you'll want to serialise a lot of things that aren't quantities.
>
> And what I'm trying to say is: I don't think there is anything common
> between the type 'flux' and the type 'position' that merits having a
> 'quantity'.

The benefit of having a general purpose Quantity class which is an
aggregation of a standard set of optional components, is that you can
produce a single programming interface to handle all sorts of Quantity,
rather than having to produce different interfaces for every individual
subclass of Quantity. This is much easier to use, and to maintain, than a
complex inheritance hierarchy. I think this is commonly being recognised
in the OO community these days - see for instance Joshua Bloch's book
"Effective Java" item 14 (titled "Favo[u]r composition over inheritance").

And there need be no danger of comparing a flux with a position, if you
adopt the right interface for the class. For instance, if you adopt the
model which Mark Cresitello-Dittmar described:

>
>
> My current thinking for our model is to define a thing which has:
>    + Axis Frames (with Mappings between) <- defines data axes
>    + Value Frames (with Mappings between) <- defines Units etc.
>    + Dimensionality/data_type etc. <- provides access to 'values'
>

then the Quantity class would have a method which returns a specified
element of the value list of the Quantity in a *requested value system*
That is, the client asks the method to "give me the 10th value in this
Quantity as a flux value in Jy", or "give me the first element as an
(RA,Dec) pair relative to equinox J2001.2". Since the Quantity contains
knowledge of what the numbers in the value list represent, *or can be made
to represent*, (i.e. using Mappings associated with the "Value Frames")
the method knows whether the client's request can be honoured. If it
cannot convert the value to the requested frame, then it either reports an
error or (more likely) returns some sort of "null" or "bad" value
indicating that the requested value is undefined.

So to do a comparison of two arbitrary Quantities, the client selects a
common value system (e.g. "flux in Jy"), and then gets the value of
each Quantity in this common system using the method described above,
checks that the two values are defined, and if so, does the comparison.
The Quantity interface could also contain a method which "suggests" a
suitable common value system. That is, a method which looks through
the "Value Frames" of both Quantities for a value system which is
present in both (or for a pair of systems which it has in-built knowledge
of how to transform between, such as (RA,Dec) and galactic coords).

I think errors (and other things) should be an optional component in a
general purpose Quantity model. There would be two ways of handling this
in the class interface:

1) Have a "hasErrors" methods which returns a boolean saying oif the error
component is present, then allow the client to branch depending on the
result.

2) To avoid the complication of needing to check for the presence of
errors, it could still be legal to invoke the "getErrors" method even if
the Quantity contains no errors, the result being a null or bad value
indicating that the error is undefined.

The NDF data model has handled errors in this way for decades and it
works. It makes simple things simple and hard things possible.

David

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX