[QUANTITY] The quandary

[David Berry]

I think an important question which needs considering here is what do we
want to do with a Quantity? An example Ray mentioned last week was
comparison:

   Quantity q1, q2;
   if( q1.greaterThan( q2 ) ) {
      ...

The problem with any such operation which combines or compares Quantities
is that you have to transform them into a common system before performing
the operation. This potentially has many aspects. The simplest aspect is
the issue of Units: obviously if you are comparing a frequency in Hz with
another frequency in GHz, the Quantity class needs to transform them into
the same units before comparing them - simple enough. But as I mentioned last
week, there are many Quantities which are not completely defined simply
by a Units string. Continuing with the above example, a frequency is not
completely defined without knowing its rest frame. So when comparing your
two frequencies you should not only transform them into the same units
but also into some common rest frame. But to be able to transform between
two arbitrary rest frames each Frequency object needs to specify lots of
extra information: e.g. the nature of the rest frame (geocentric, topocentric,
heliocentric, LSRK, LSRD, etc), the observers position, the source
position, the time, etc. All of these are needed to completely define the
frequency. And there will be many other quantities which likewise need a
sophisticated collection of data to be completely defined.

So I think we need to generalise the statement made by David that "a
Quantity is simply a value and a unit". I think a Quantity should be "a
value and a Domain". Here, I use the word "Domain" to mean an object
which completely describes the physical domain in which the quantity
lives. The base Domain class could simply have a Unit attribute and a Name
attribute (I would say a UCD if I knew what a UCD actually is - I was a
bit confused by last weeks discussion - was I alone?). If both Name and
Unit are null, then a Quantity behaves just like a primitive double or
float (i.e. it has no definition and comparisons are based purely on the
numerical value). If Name is not null, then it means that you can only
meaningfully compare values in the Domain with values in Domain with the
same Name. If Unit is not null, then additionally, the other Domain must
have a Unit which is dimensionally equivalent (e.g. "km" and "AU", "s" and
"Myr", etc).

For instance, you may use a simple Domain to describe an "arc-distance"
quantity, with Unit="rad" and Name="ARC-DISTANCE". This would be
sufficient since (as far as I am aware), arc distance needs no other
qualifying information.

For more complex quantities, you would sub-class Domain. So for instance
you could define a SpectrumDomain. This would know that positions in a
spectrum can be described by wavelength, frequency, various velocities,
etc, and it would contain all the extra information needed to completely
define the transformations between these descriptions. Other examples
would be SkyDomain (for positions on the celestial sphere) and TimeDomain
(for... times).

Your Quantity object would then contain a collection of numerical values
plus a Domain object which describes the coordinate system to which the
values relate (using "coordinate" here in its broadest sense in which, for
instance, "flux density" can be considered a coordinate).

All the above says nothing about errors, resolution, etc. I think I agree
with David that describing these sorts of things is a separate problem
which should be handled at a higher level. Once you have defined a
frequency Quantity, you can use it to describe anything you like: a
central frequency, a frequency error, a frequency resolution, or any
other use of frequency. One big problem with the idea of encapsulating an
error within a Quantity is that there are many different ways of defining
"an error". So you would need to include some extra information explaining
what sort of "error" was included in each quantity. Likewise with
resolution. My preferred way to handle errors, etc, would be to have a
higher level object which encapsulates several Quantities, one for the
central value, one for the error, one for the resolution, etc, as needed.
This higher level object would then have the job of interpreting what is
meant by an "error" or a "resolution".

David


On Wed, 21 May 2003, David Barnes wrote:

>
> Arnold et al.,
>
> first up let me say I wasn't at the meeting, so if I repeat
> things already discussed please say so.
>
> Ray's powerpoint proposes a Quantity as a value, an error and
> a unit.  Arnold has extended and modified this to be a
> value+unit/s, error+unit/s, resolution+unit/s, size+unit/s,
> and pixelsize+unit/s.
>
> I believe a Quantity is simply a value and a unit.  Nothing
> more, nothing less.  The unit can be "null" if necessary,
> and the value may be a vector.  This is the AIPS++ way, and
> I hope that I don't put people off reading the rest of my
> comments because I've now mentioned the "AIPS++" word.
>
> What Ray and even more so Arnold seem to me to be describing
> is something like a "measurement", not a "quantity".  It is
> in the process of measurement that you introduce concepts
> like error, resolution, pixelsize - they are in general not
> fundamental to the quantity itself.
>
> At this point, I wondered then if you simply renamed your
> Quantity to be a Measurement, and then each of the fields
> in your Measurement become Quantities like I have described
> then we might agree.  However, there are two further properties
> involved in measurements:
>
> - the frame (eg. crucial for converting observed line frequencies
>      to radial velocities)
> - the sampling which is chosen by the user and is consistent with
>      the instrumentation and processing (eg. the pixelsize concept)
>
> AIPS++ deals with the frame by introducing its concept of a
> Measure.  An AIPS++ Measure is one or more Quantities and a
> reference frame.  For example, a DirectionMeasure comprises
> two Quantities with angular units, and a reference frame which
> might be "J2000" or "GALACTIC".  I personally don't prefer the
> semantics here, and it might be more explicit to call something
> like this a FramedQuantity.  If it were a truly measured thing
> with associated error and/or resolution (for which an object
> doesn't exist in AIPS++) then I would call it a FramedMeasure.
>
> Beyond this, I think the sampling is intrinsic to the way the
> data is stored, and is generally independent of the resolution
> and/or errors.  In fact isn't the sampling (pixelsize) a function
> only of the CoordinateSystem, ie. the mapping of an ordered set
> of values in storage to real world values?  So the sampling is
> handled if you use FramedQuantities or FramedMeasures to define
> the location of eg. the centre of your image, and plain old
> Quantities (with units like arcsec/pix, MHz/pix) to define the
> pixel increments.
>
> I'm not sure if the above will make much sense, but I basically
> wanted to alert this group to the path AIPS++ has taken down
> this route, and promote a simpler starting point for quantity
> (just a value plus a unit) which can be built upon to derive
> measured things with errors, resolution, and reference frames.
>
> Perhaps there is a good reason already discussed about why a
> quantity needs error, resolution, ..., but I haven't heard it.
>
> If anyone is interested in the AIPS++ approach, you might like
> to see the "quanta" and "measures" sections of the AIPS++
> reference manual:
>
> http://www.atnf.csiro.au/computing/software/aips++/weekly/docs/user/Refman/Refman.html
>
> - David.
>
>