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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cc4f25d878383cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-11 11:11:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!ppp-1-52.cvx6.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: Tue, 11 Dec 2001 19:05:46 -0000 Message-ID: <9v5loh$d5aki$1@ID-25716.news.dfncis.de> References: <11bf7180.0112070815.2625851b@posting.google.com> <9v0crt$bo2bi$1@ID-25716.news.dfncis.de> <9v37rs$cdmva$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: ppp-1-52.cvx6.telinco.net (212.1.156.52) X-Trace: fu-berlin.de 1008097874 13806226 212.1.156.52 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:17782 Date: 2001-12-11T19:05:46+00:00 List-Id: "Stephen Leake" wrote in message news:upu5ln22l.fsf@gsfc.nasa.gov... > "Nick Roberts" writes: > > > It's easier to demonstrate than to actually explain. Show me a piece of > > (genuine) Ada code that uses a floating point type to hold values that would > > be usefully made unit-specific, and I'll show you how they certainly could, > > and probably should, be held by a fixed point type instead. > > http://users.erols.com/leakstan/Stephe/Ada/Sal_Packages/index.htm, > file sal-gen_math-gen_dof_6.ads > > This is part of the math library I used to implement robotics control > systems and satellite simulators. > > The core type is a 6 dimensional "pose", consisting of a 3 dimensional > position vector (x, y, z) and a 3 dimensional rotation, represented by > a unit quaternion. The position vector should be in meters (or feet, > if you are a barbarian :), the quaternion is unitless. > > For robotics, the position is computed by the forward kinematics > function; V = F (theta), where V is the (x, y, z) vector, and 'theta' > is the vector of joint angles. > > The joint angles are properly represented by fixed point numbers, > since they have constant error. A joint angle is measured by hardware > with a fixed precision; the value is known to plus or minus 0.001 > radians, for example. When you run that thru the function F, which > contains Sin, Cos, multiply, and add, you get a relative error; 'x' is > known to 1 percent. Thus x is properly represented by floating point. This example, in fact, actually illustrates my point, I believe. My point is that, because dimension checking could not be performed statically inside the function F, and it would probably be unacceptably slow to implement it dynamically, you lose nothing by not having the dimension checking. Since you use radians throughout inside the function F, internal unit conversion (scaling) is also not required. Nevertheless, you get both dimension checking and unit conversion outside function F. All non-unit-specific scalar types will be assumed to have a scaling factor of 1.0. So, e.g.: type Joint_Angle is delta 0.001 range ... unit Angular_Degree; -- Angular_Degree has scaling factor pi/180 function F (A: Float) return Float; -- in radians A1, A2: Joint_Angle; ... Read(Detector(D),A1); A2 := Joint_Angle( F( Float(A1) ) ); The conversion Float(A1) will multiply A1 by the scaling factor pi/180, thus rendering it in radians, and the conversion Joint_Angle( ... ) will divide the result by pi/180, hence converting it back into degrees. A1 and A2 will both be specifically dimensionless (their dimensions are all 0), and for calculations between them and other unit-specific (fixed point) types dimension checking will be performed. > More practically, most computers used for robotics and satellite > simulations support fast floating point, often faster and more precise > than integer. So there is no reason to use fixed point. But nothing prevents a compiler from implementing fixed point operations/representations using the hardware's floating point unit/format. (Am I wrong?) > > I'm not actually trying to argue that floating point types should > > never be used for non-unitless quantities. > > Good > > > All I'm suggesting is that there is no practical need to add the > > unit-specific facility to floating point types. > > I disagree. I started one, and gave up when I hit the combinatorial > explosion others have alluded to. It would be useful to find bugs > during unit test. > > The most practical implementation I've seen stores a count of the > order of the three basic dimensions (mass, length, time) with each > value. Multiply and divide add and subtract those counts; addition and > assignment check them. This is good for finding bugs, but it is too > much overhead for bug-free real-time execution. I am suggesting that the proposed facility is designed so that most or all checks could, in practice, be performed at compile-time. I suspect the facility would have to be specified in the standard in terms of dynamic semantics (because making it formally static would be just too nasty), but this wouldn't prevent compilers from doing (most) things at compile-time in practice. Compilers should (be recommended to) provide a three-way switch, I suppose: dimension checking off; dimension checking on (compile time if possible, otherwise at run time); dimension checking only at compile time (run-time checking simply removed, maybe with a warning). > > Furthermore, I think it would be horribly painful trying to do so > > (consider Ada.Numerics). > > It is horribly painful, but not because of Ada.Numerics. > > It is simply wrong to try to define units for trig and exponential > functions. Remember the Taylor expansion for Sin: > > Sin (x) = x - 1/6 x**3 ... > > If x has dimensions of meters (shudder :), then what are the > dimensions of Sin (x)? This is why angles must be dimensionless, as > radians are. Angles are dimensionless, as you correctly point out, but so is X (it is a ratio). Hence, suppose we have a declaration such as this: generic type Ratio is delta <>; type Angle is delta <>; function Sin (X: in Ratio) return Angle; Provided the types Ratio and Angle were both dimensionless, the internal computations would all be dimensionless throughout (X**N is dimensionless, for all N, if X is dimensionless). Hence the dimension checking would work perfectly in this case (if either Ratio or Angle were not dimensionless, the compiler should squeal). I believe it is likely a compiler would be able to fully unroll the computation loop, and so do all the necessary checking at compile-time. The instantiator of the function should choose a type for Ratio which has a scaling factor of 1.0, and a type for Angle which represents radians (and so also has a scaling factor of 1.0). So, shudder not! > If you don't take the stored counts approach, you have zillions of > routines to write just sticking with SI units (meters * time, > meters**2 * time, (meters**2 * kg) * time**2, etc). Adding unit > conversion makes it far worse. The whole idea of what is being proposed is to do away with all that (or much of it). > > -- > -- Stephe -- Best wishes, Nick Roberts PS: I have quoted at length, as I thought it necessary. Hope nobody minds.