[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed numeric type hierarchy



James Knight writes:
> 
> 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?

I don't think there is one. "Scalar" is a really crummy word, because
it's usually defined as a real value, but everyone uses it to also
mean "not a vector". So you have definitions like: a scalar field is a
function R^n -> R, which leaves you out of luck with complex numbers.

Maybe you could rename <scalar> to <qty>, and <qty> to <dim> (for
<dim>ensioned value)?

> > 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.

What you could do is have a set of base units, like <meter>, <kg>, and
<sec>. Then you could add two type constructors, for creating derived
units by multiplying and dividing units. So

(dv <spd> (div <meter> <sec>))             ;; units of velocity,
(dv <vol> (times <meter> <meter> <meter>)) ;; units of volume.

Then, you could create a dimensioned value type with another type
constructor, which takes a unit and a number type. So you would then
write (of <dim> number <flo> unit <spd>) to get a velocity measured
with <flo> values. This would let you make get things to work the way
they intuitively should.

-- 
Neel Krishnaswami
neelk@alum.mit.edu