Units package (was Method names)

Sam Adams ssadams at us.ibm.com
Mon Nov 2 22:26:38 UTC 1998


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.

Regards,
Sam
Sam S. Adams, Distinguished Engineer, IBM Network Computing Software Division
tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>





More information about the Squeak-dev mailing list