[QUANTITY] and [SIMPLE]: Forking the discussion

[Jonathan McDowell]

The goal of QUANTITY must be to define how the more complicated cases
hang together. For a given level of complexity of QUANTITY, we directly
define how any of the simpler subobjects (Q-only-value-error,
Q-only-value-unit, etc) interact. It's not that you can't use the
simpler objects, but we don't need to put effort into defining them
because they fall out directly from the more complicated one. 
                    
  The downside of increased complexity is the increased  difficulty
of deciding on a definition. So, we win by picking a level of intermediate
complexity which matches as well as possible to things we actually
see in our astronomical datasets while being simple enough to make
progress.

At Cambridge and Strasbourg we identified two such layers,
OBSERVATION to describe a whole dataset, with the understanding that
must include the example of a 2D sky image, and QUANTITY to describe
numbers and arrays associated with a physical concept, to be used
as a building block for OBSERVATION. My touchstone for QUANTITY is
that it should contain everything that is associated with a single
astronomical/physical concept, which is why I'm happy to include
units and errors but nervous about including mappings ("arguments"
to quantity in terms of the earlier discussion). Brian has just
argued that in fact the mappings problem is not separable because
it will affect the rest of Quantity; I'd be interested to hear
his specific arguments on this.

Based on the discussion so far, and particularly the level of
consensus described in my summary at the end of October, it seems
that when you *do* have errors and units, they belong with
the values and they belong in the thing we have been calling QUANTITY
and that is a useful thing to define; moreover it trivally supports
all the simpler cases being discussed within a single interface.
It does not stop you dealing with numbers without errors, it
just lets you carry around the errors with no added effort
if you happen to have them.

As DM chair I would like to decree that at least for the time being
[QUANTITY] shall refer to a model which supports at least values, units
and errors and a physical concept, and that further discussion of a
model referring to simpler objects (other than as subclasses for
QUANTITY) should be forked to a thread called [SIMPLE].

It is potentially productive to come to agreements on objects on both
these levels. It is no longer productive to continue arguing which of
these two objects we should be defining. Once we have iterated more on
definitions, it may be productive to argue whether a [QUANTITY] or a
[SIMPLE] object should be used in a particular aspect of [OBSERVATION].
I will circulate a futher summary on QUANTITY and OBSERVATION in a few
days.

  Jonathan

PS: On errors versus simple numbers: We don't need to define a class for
a simple number - we have classes for that already, called 'integer' and
'double' (or whatever in your favorite language).