Re: Types with physical dimension

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <36tole$j5e@cyclope.enst.fr>, rosen@enst.fr (Jean-Pierre Rosen)
writes: 

|> Alternatively, you can make the dimensions discriminants; this will improve
|> safety and allow you to define nice subtypes like: 
|>    subtype Meters is Physical(1, 0, 0, 0);
|> but will make moving to plane Floats more difficult.
|>
|> Acknowledgements: 
|>   I saw this idea in a paper long ago. As far as I recall, it was by
|>   N. Cohen. Norm, are you listening?

Yes, I'm listening.

I wrote the paper under the pseudonym "Paul Hilfinger".   :-)

Here is the reference: 

   Paul N. Hilfinger.  An Ada package for dimensional analysis.
   ACM Transactions of Programming Languages and Systems 10, No. 2
   (April 1988), 189-203

But seriously, folks, I disagree with Paul's approach.  In the absence of
heroic measures on the part of the compiler, besides imposing an added
run-time overhead, it defers until run time the detection of errors that
can be caught by static analysis.  I've long felt that the best way to
address this problem is at compile time, with a tool that takes a tabular
specification of a system of units and generates a series of declarations
declaring distinct types for distinct units, along with trivial
subprogram bodies for overloaded versions of "*", "/", and "**".

One complication in this approach is the need to define types for
intermediate results that do not correspond to natural physical units.
For example, the number of ergs spent in applying, over a distance of D
centimeters, the amount of force required to accelerate a mass of M grams
A centimeters per second per second is M*D*A.  The intermediate result
M*D is measured in gram centimeters, a physically meaningless unit.  Had
we written M*(D*A) instead, the intermediate result D*A would be measured
in terms of centimeters squared over seconds squared, also physically
meaningless.  The tool must generate types for a reasonable number of
such intermediate units of measure.  There are an infinite number of
possibilities--for example computing a mass by dividing mass to the fifth
power by mass to the fourth power--that are not likely to arise in real
expressions, but some rather strange-looking units like time to the power
-2 ARE likely to arise.  The trick is knowing where to draw the line so
that a user of the automatically generated package will not be surprised
by the illegality of a given expression.

Another complication is scaling, when converting between different
systems for measuring the same kind of quantity, such as the cm-g-sec
(CGS) system and the m-kg-sec (MKS) system, or mixing units from
different systems.  One solution is to provide conversions only for a
given kind of physical quantity--between kilograms and grams, or between
meters and centimeters, for example, and to provide combining operators
only within a given system.  Thus you can't multiply kilograms times
centimeters per second squared to obtain a force.  You have to convert
kilograms to grams and apply the CGS operators to obtain a result in
dynes, or convert centimeters to meters and apply the MKS operators to
obtain a result in newtons.  If all these types are implemented as real
types rather than private types, so that real literals can be used in
expressions, then a conversion between, say, Dyne_Type and Newton_Type is
automatically defined as a basic operation, but it does not have the
right semantics.  (It does not scale upon converting.) It is easy to
write conversion functions that do the right thing, but there is no way
to hide the automatically defined type conversions, which a programmer
could easily be seduced into using by mistake.  (The "is abstract" trick
cannot be applied to type conversions.)

--
Norman H. Cohen    ncohen@watson.ibm.com