[QUANTITY] Review of Quantity suggestions

[Ray Plante]

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 
and measurements we have an opportunity to add additional components to 
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