[QUANTITY] why we should have string values in quantity

[Ray Plante]

Hi Brian,

Sorry, but I didn't find your examples very convincing.  The fact that the
error and math tests fail is a signal that you are not being semantically
true to the definition.  This is much the same the problem as when you
sub-class a class and find that you have to implement of some of the
methods with just a throw statement because they don't make sense in the
sub-class context.  This is a sign that something is wrong with the
application of the model.

On Mon, 3 Nov 2003, Brian Thomas wrote:
> The best case I can come up with is the possibility that as
> user/data repository wants to put one or more quality flags on the
> string datum.  

It's not necessary that Quantities be the only thing that can have
"quality" associated with it.  

> But thats not a terribly strong case to make for strings. I prefer the
> following instead: Yes, its true that you cant multiply and divide
> strings. But you can map them to numerical values that are operable in
> that fashion (use-case below). 

Even if you do this, it doesn't mean that the math you do on it makes
any sense.  Consider the FITS convention for Stoke axes (where the
various polarizations are given numbers so that they can be mapped to
an image axis, thus supporting IQUV cubes).  Because polarization type
is not a real quantity, you have the following problems:
   *  multi-polarization cubes is only practical for full Stokes image
      cubes (where the mapping to integers are consecutive)
   *  polarization pixels have no sensible width.
   *  interpolation, extrapolation of position makes no sense.

This makes life difficult for general purpose N-D visualizers (which I can 
attest to first-hand).  Nevertheless, this scheme is used due to the 
limitations (at the time of its inception) of the FITS model for image 
axes.  

> Use-case: Consider that the string quantity "M31" might be mappable to
> a numerical quantity "Sky Coordinates" that has Ra, Dec that you may
> operate on.  This allows a search for "M31" to auto-matically expand
> to a coordinate search (or, in cases vice-versa).

Name resolution is a necessary capability; however, supporting this
does not require string support in a low-level Quantity.  If "Sky
Coordinates" is a higher level model (as I've advocated given the
amount of ancillary data that is necessary), then this expansion would
naturally happen at that higher level.  

Note also that at the level of software, it is not a problem if
someone wants to enable of view of a string in terms of a Quantity.
This is similar to the discussion we've had about viewing images as
tables and vice-versa.  Sometimes this might be useful; however, this
does not mean that our image data model needs to include a concept of
a table column nor our table model, a concept of pixel.  

cheers,
Ray