Re: Types with physical dimension

[gamache@rapnet.sanders.lockheed.com]

In article <CxBBx8.7L@irvine.com>, 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;
-------------------------------------------------