Re: Proposed numeric type hierarchy

[James Knight <jknight@xxxxxxxx>]

On Monday, October 21, 2002, at 08:28  AM, Neel Krishnaswami wrote:
>> ;; I hope this is the right use of the term 'scalar'
>> (dc <scalar> (<any>))
>
> Unfortunately, it's not. Scalars are real values, which means that
> complex isn't an appropriate subclass for them.

I was hoping the important piece of meaning was "not vector". What's a 
better term?

 From Webster's Revised Unabridged Dictionary (1913) [web1913]:

   Scalar \Sca"lar\, n. (Math.)
      In the quaternion analysis, a quantity that has magnitude,
      but not direction; -- distinguished from a vector, which has
      both magnitude and direction.

 From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:

   scalar

      1. <mathematics> A single number, as opposed to a {vector} or
      {matrix} of numbers.  Thus, for example, "scalar
      multiplication" refers to the operation of multiplying one
      number (one scalar) by another and is used to contrast this
      with "matrix multiplication" etc.

> It strikes me that parameterized classes might be the best way of
> representing dimensioned types. If you've got a numeric hierarchy of
> N classes, and M types for dimensions, any of the M x N possible
> classes are credible, eg (of <meter> <int>) or (of <meter> <flo>).

I was thinking that <qty> should be parameterized  on the kind of 
quantity it contains. The main thing it needs to handle is having any 
combination of units. Ala "m^2", "m/s^2", etc. Creating a new class for 
each of those isn't doable, as there are an essentially infinite number 
of them, but it's a perfect match for parameterized types.

I hadn't thought much about the problem of the different contained 
types. In fact, I think it actually might not make sense to say it can 
carry an integer at all, since doing something like "5inches" will 
return (* 5 2.54) cm, which will not be an int. Or 1mm, which is also 
not an int. Now, certainly, it is still possible to have integral 
quantities; I just question whether it is useful. Maybe quantities 
should be represented with <flo>s always.

Of course, a similar situation comes up when discussing <ratio>, and 
<complex>, as they are both composed of other numeric types. Ratio 
isn't a big deal, as it can only be composed of <int> subtypes, which a 
user likely doesn't care about too much. However, it is possibly 
important to be able to distinguish a complex composed of <int>s and a 
complex composed of <float>s. That is, unless it is acceptable to 
restrict complex numbers to only contain floats, which it may be...

James