Re: Proposed numeric type hierarchy
Neel Krishnaswami <[email protected]> Wed, 23 Oct 2002 11:30:07 -0400 (EDT)
| Newsgroups | gmane.comp.lang.goo.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]