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 09:17:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: 11 Dec 2001 11:39:30 -0500 Organization: NASA Goddard Space Flight Center Message-ID: 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: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1008088962 2410 128.183.220.71 (11 Dec 2001 16:42:42 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 11 Dec 2001 16:42:42 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:17769 Date: 2001-12-11T16:42:42+00:00 List-Id: "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. 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. > 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. > 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. 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. -- -- Stephe