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.8 required=5.0 tests=BAYES_00,INVALID_DATE 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-15 00:04:48 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!udel!MathWorks.Com!yeshua.marcam.com!uunet!sparky!kwiudl.kwi.com!netcomsv!netcomsv!butch!rapnet.sanders.lockheed.com!rapnet.sanders.lockheed.com!gamache From: gamache@rapnet.sanders.lockheed.com Newsgroups: comp.lang.ada Subject: Re: Types with physical dimension Date: 13 Oct 94 17:15:05 -500 Organization: Lockheed Sanders, Inc. Message-ID: <1994Oct13.171505.1@rapnet.sanders.lockheed.com> References: <1994Oct4.194510.22580@wdl.loral.com> NNTP-Posting-Host: dune.sanders.lockheed.com Date: 1994-10-13T17:15:05-05:00 List-Id: In article , adam@irvine.com (Adam Beneschan) writes: > mab@dst17.wdl.loral.com (Mark A Biggar) writes: > >> > Paul Hilfinger did a nice paper on using discriminants to check >> >dimensionality. I don't have the paper in front of me but it works >> >something like this: >> > type Measure(Length,Mass,Time: Integer) is record >> > Value: Float; >> > end record; >> > subtype Meters is Measure(1,0,0); >> > subtype Kilograms is Measure(0,1,0); >> > subtype Time is Measure(0,0,1); >> > ...etc. this part of the original post was snipped: >Now you can define all the standard arithmetic operations on type >Measure so that they keep the discriminant correct: > >function "+" (L,R : Measure) return Measure is >begin > if L.Length /= R.Length or L.Mass /= R.Mass or L.Time /= R.Time > then raise Constraint_Error; end if; > return L.Value + R.Value; >end "+"; I *really* liked this for a while after I saw it. For some scary reason, I guess I kept thinking about it in the back of my mind and now I'm not so sure. Couldn't I declare: Not_Kg : Measure(1,1,1); Not_Time : Measure(1,1,1); and then bypass all the protection this schema offers? Maybe use of membership tests in the if statement would help? But then again, I guess I never understood the *big deal* with units here anyway. Skipping to the chase scene: its my contention that most unit-related problems are systemic from engineers not wishing to declare the same units twice (or more). It's like, well we're building a couple 100K lines of code and I'm really gonna save by only defining Kilograms (or worse PI) once! My thinking is that if inside a given unit one is implementing D=R*T (distance = rate * time) then define all typesb as subtypes of a parent type that can be combined: subtype Feet is Float_32 range a..b; subtype Feet_per_Sec is Float_32 range c..d; subtype Sec is Float_32 range e..f; (assume float_32 is a 32-bit redefinition of a predefined type). Now variables can easily be combined in the necessary fashion WHILE AT LEAST INSURING VALID RANGE CONSTRAINTS ON THE INPUT DATA. In the example above one could envision either negative values (removable via a range constraint) or fractional values that may be nonesensical for certain inputs. Later in the application, some other object may need a type for seconds as well. In my experience often times these two objects never meet. So I say - define another type! In those interfacing situations between objects where there is commonality (in say the Seconds type) then I like the approach of a Time Package which provides needed operations (including conversion to float_32). Given the ability to build larger objects from small, isn't this the intent anyway? Just my 0.01 (two cents adjusted for inflation). ------------------------------------------------ with all_necessary_disclaimers; use 'em_2; -------------------------------------------------