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-12 06:17:48 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: 12 Dec 2001 09:16:21 -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> <9v5loh$d5aki$1@ID-25716.news.dfncis.de> <9v6iv7$dcrbf$2@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 1008166769 28954 128.183.220.71 (12 Dec 2001 14:19:29 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 12 Dec 2001 14:19:29 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:17831 Date: 2001-12-12T14:19:29+00:00 List-Id: "Nick Roberts" writes: > "Stephen Leake" wrote in message > news:u7krtl5u8.fsf@gsfc.nasa.gov... > > > F returns a position vector (x, y, z), in meters. So I'm not clear > > what this should be. > > Something like: > > > V := F(...); > A := ( Joint_Angle(V.X), Joint_Angle(V.Y), Joint_Angle(V.Z) ); > > > That's all. Well, V is _not_ a vector of "angles", it is a vector of "Cartesian positions". I guess you should do: V := F (...); M := Cartesian_Position (V); Where Cartesian_Position does some scaling. But I repeat, I see no advantage here. I can easily and efficiently define F to return a vector of meters. > > as someone else pointed out, these three choices are orthogonal. > > I'm not arguing about that. It would be nice to provide the facility for > floating point numbers, I don't deny it. I just think it would be hard, > that's all. But if it's needed, then it's needed. Huh? Why would it be harder for float than fixed? > > I still think you'll get an explosion of types, like Meters, > > Meters_Squared, Meters_Per_Second, Meters_Per_Second_Squared. How > > else do you specify the dimensions? > > This is correct (you'll get a lot of types, one for each unit, which > encompases a dimensionality and a scaling factor). > > > So you'll still have to define > > all the inter-type operations. I suppose you define some sort of > > automatic operator generation for this, but that's an even bigger change. > > Many (most?) of the required inter-type operations will be provided as > predefined operations. This in itself is not a big change, since Ada 95 > already provides it! Um, no. In Ada 95, I can do: type Meters is digits ...; type Seconds is digits ...; type Meters_Per_Second is digits ...; Ada 95 does _not_ define the following, which is needed: function "/" (Left : in Meters; Right in Seconds) return Meters_Per_Second; Ada 95 _does_ define the following, which is wrong: function "*" (Left, Right : in Meters) return Meters; Now, if you are defining a new language feature, it would be really good to get this right. Maybe something like: type Meters is units digits ...; type Seconds is units digits ...; type Meters_Per_Second is units compose Meters / Seconds; Then the compiler will _not_ generate multiply and divide operations for "units" types, but _will_ automatically generate the appropriate ones for "units compose" types. I just made this up, so there's probably lots of holes in it. > > > Angles are dimensionless, as you correctly point out, but so is X (it is > a > > > ratio). > > > > Well, you said you would convince me of that, but I don't see any > > argument for making X a ratio. I defined it as meters. I could pick > > some arbitrary length (say the length of the robot forearm), and > > define all other lengths in terms of that. But that would be horribly > > confusing! What's wrong with meters for X? > > See other posts in this thread. X must be 'dimensionless' in the sense of > having dimensions of all 0. If X is to be passed to a transcendental function, yes, it must be dimensionless. But that's _not_ what I'm doing with X! I am _defining_ the position of the end of a robot arm to be V == (x, y, z). By _definition_, x, y, and z are in meters. As such, it is _meaningless_ to pass x to a transcendental function. That's fine; the mathematical meaninglessness simply reflects a physical meaninglessness. There is no meaninful physical operation that corresponds to Sin (meters). -- -- Stephe