From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,791ecb084fdaba75 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-05 12:53:40 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada Subject: Re: Types with physical dimension Date: 5 Oct 1994 15:48:06 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <36uhrm$16m7@watnews1.watson.ibm.com> References: <36tole$j5e@cyclope.enst.fr> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Date: 1994-10-05T15:48:06+00:00 List-Id: 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