[QUANTITY] why we should have string values in quantity

[Brian Thomas]

On Monday 03 November 2003 02:08 pm, Jonathan McDowell wrote:
> Brian and Ray,
>  Just for the record, and I probably have said this already, the
> real reason I want to see Q support strings is because I already
> have a lot of software that operates on things very like a Q which
> includes string-valued things. Indeed, in my mind Q is something
> which can be used to represent FITS keywords and FITS table columns,
> both of which are objects which are very like our discussions of Q
> and which one often wants to perform metadata operations on independent
> of whether they are string or numeric valued. This real world
> situation - that the thing in our data now which most closely maps
> to Q is something which can be either numeric or string valued and
> which shares common metadata and methods - convinces me that having
> Q support strings, even though some of the other things like error etc
> will be unused in that case, is more convenient than having two separate
> classes.
>  I further submit (pace Gerard) that not all strings are classifications;
> sometimes it can be formatting (sexagesimal positions) and sometimes
> descriptions, among probably other cases.

	Ray, all,

	Ok, my "error" justification sucked. And my argument for mapping 
	strings to numbers isn't a justification for strings in quantities (that 
	mapping may occur at a higher level). I still agree with Jonathan that 
	strings are important because they are part of the basic "data" that 
	we all have.

	Perhaps the relationship between "StringQuantities" and "NumericalQuantities"
	may be made clearer by further analysis of their respective cardinal
	quantity meta-data:

        Meta data       Strings Have     Numbers Have
        --------------        ------------------      ---------------------
         Mapping/Trans    yes                        yes
         Data Type          yes^1                     yes
         Accuracy            no                         yes
         Units                  no^2                     yes
         
	1. "Type" is usually "string", but could be "char" (as well as the encoding used)
	2. Possibly the case for units in strings: units are always default to "unitless, precise value".
            I'll accept that most people feel this is a "no" and acquiesce to the masses.

	And strings may have definitely have dependence on other quantities. Imagine a 
	quantity for galaxy name that contains string values and depends on coordinates,
	e.g. galaxyName(ra,dec). Or perhaps just depends on the row index, as in a column 
	of galaxy names.

	This points to a possible resolution (?) : class hierarchy where there is a parent class
	of "quantity" that has only properties of "value", "datatype" and hooks for mappings. 
	And the inheriting child classes of "numberQuantity" (adds in hook for units and accuracy)
	and String (adds only semantic meaning that it is a string)

 	Regards,

	-b.t.