Sam Adams wrote:

> alank wrote:
> <<Reinier --
>
> We've talked a lot over the years of adding "units" (centimeters, feet,
> grams, ounces, bits, bytes, etc.) to Smalltalk. They are very useful in
> science for knowing what you are talking about, and in Smalltalk would be a
> set of unarys (as you suggest) that help conversions to be made. (They also
> could be symbolically executed to just get the dimensions of the quantity
> ....).
>
> Any interest out there in making a great units package for Squeak?
>
> <snip>
> >>
>
> Yes, I'm interested.  I implemented a start for such a package years ago and
> learned a great deal but the code was lost.
> If I remember correctly the main objects in the framework were Measurement,
> Measure, MeasurementSystem, Unit and a few others.  It used coercions based on
> a "gold standard" for conversions and lots of unary messages for syntactic
> sugar (inch in inches squareInches cubicInches etc).
>
> Some experiences:
> Unit conversions within a MeasurementSystem are trivial:
>  ( 1 inch + 12 feet ) asYards
> Unit conversions across MeasurementSystems( English vs Metric) for the same
> Measure (Linear, Area, Volume) were easy for addition and subtraction
>  (3 meters - 2 feet) asAngstroms
> Multiplication and division were OK (LinearMeasure * LinearMeasure yields
> AreaMeasure)
>  (2 feet * 10 meters) asHectares
>
> What got complicated fast (and what I never finished) was the general case
> which ends up with composite units like furlongs per cubic fortnight per dyne
> centimeter.
> You then needed an algebraic system with mappings for unit definitions (dyne cm
> = erg, etc) so these composite units could recognize whether they were
> compatible or not and if the units could be reduced or mapped to another unit.
>
> The really cool stuff you could do with a system like this is divide aDistance
> by aTime and get aVelocity and divide by aTime again and get anAcceleration,
> then multiply by aMass and get aForce.  Each Measurement object would be the
> natural place to implement all of those equations we learned in Physics.  I had
> dreams of an environment like Morphic where animated measurement objects would
> collide and react almost chemically, perhaps implementing an updated version of
> the old General Problem Solver.  <sigh>
>
> One other piece of advice: check out a book on measurement theory or find a
> MathPsych major for tips on abstractions for this domain.
> Oh yes, Kent Beck and Ward Cunningham's experiences with financial modeling
> with deferred currency conversions would also be excellent here.  They had some
> great models that might be useful.

When I worked at Siemens, Ken Greene had implemented a very elegant measured value
system. I actually did a lot of the work on it, but the true novelty of the
mechanics was his brainchild. The cool thing about it was the way it automatically
reduced and composed units under multiply and divide operations. I did tons of my
thermodynamics homework where mixed units were the thing with it. I would just type

(3.0 => 'pa') / (4 => 'in2')

Select print it and out woud pop 0.75 => 'psi'. Multiply that by 5.0d => 'in3' and
out would pop 2.25 'in'. It dealt with mixed units great too.

One of the goals of adding double dispatching to the math core was to add that
package or something like it. I could either do a clean room implementation of what
we did, or I could see if Ken feels comfortable making some of the code available
(Siemens is one of this big 'ol stodgedy thou shalt not share anything companies).
Stay tuned...

--
Travis Griggs
Key Technology
tgriggs at keyww.com
Member, Fraven Skreiggs Software Collective
 - C for Sinking
 - Java for Drinking
 - Smalltalk for Thinking