# [QUANTITY] Review of Quantity suggestions

Ray Plante rplante at poplar.ncsa.uiuc.edu
Wed Jul 23 22:29:39 PDT 2003

```Hi,

First off--excellent work by Jonathan and Steve on the review!  (I
think this is exemplary of how we should work on topics where there is a
broad range of perspectives.  The result will hopefully be a synthesis of
the best bits from all.)

Here are a few quick responses to the review document:
-  I favor a simple, aggrative model at the lowest level.  Additional
complexity can be added at higher levels (cf. Measurement).  It would
be nice if there is a lightweight way to hook in some of the
transform ideas (see below).

-  Question: support arrays (p. 8)?  yes, as it appears feasible from
the strawmans illustrated in the paper.

-  Question: specify a datatype?  I feel we should be pretty restrictive
here.  At most, we should allow floating point (not distinguishing
between "float" and "double"), integer, and complex.  I'm not even
positive about integer (someone have an example out there?).

It's possible we may get away with restricting to just floating
point, with complex being a 2-element array, but that might get a
little inelegant.

String quantities are asking for trouble.  Case in point: the
"STOKES" axis in fits.

-  I like the direction recommended by the "Interim" models.  I would
favor using these as references for discussing additions/subtractions.

Reading Pierre's response, his listing of requirements, and call for use
cases, I am reminded of where I saw this going when I first presented the
idea.  Once we have a general Quantity model, we would extend it (or
perhaps Measurement) to define such things as a Frequency, a Velocity, a
Flux, etc.  The purpose (read, one requirement) is to establish some base
uniformity in how one renders and use quantities.  As we work through
these ideas, we should test out what these more specific models might look
like.

Note that when we extend and build up more specific quantities
the model.  For example, if a particularly quantity (say, position on a
sphere) has some special error requirements, we can extend the Error model
(as JCM/SL have suggested).  This can help us keep the base quantity model
simple.  Some models have suggested some sort of generic metadata
component; this I see as unnecessary.  For example, if we have a complex
measurement concept, say, Photometry, the model can aggregate a Flux
quantity with other needed metadata (like ObservedFrequency).  (I think
defining a generic container like Metadata is sign that we're doing
something wrong.  Quantity is a little different if we expected to
subclass it to specific quantities like frequency.)

Good discussion.  (Still going through Pat's message.)

cheers,
Ray

```