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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c1400b61b3f80c1e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!postnews.google.com!u10g2000prn.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Subtypes to represent coordinate charts Date: Sat, 22 Mar 2008 10:16:21 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <87d4pr6413.fsf@ludovic-brenta.org> <47e0fc15$0$89167$157c6196@dreader1.cybercity.dk> <13u2t1a2s141531@corp.supernews.com> <1fac7b25-a11f-4199-97ad-45688318e424@u69g2000hse.googlegroups.com> <1kv438li1fcvq.ox99qnglkog5.dlg@40tude.net> <15bxm1vkv9k10.1s13j5278f2xn$.dlg@40tude.net> NNTP-Posting-Host: 166.70.57.218 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1206206181 5567 127.0.0.1 (22 Mar 2008 17:16:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 22 Mar 2008 17:16:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: u10g2000prn.googlegroups.com; posting-host=166.70.57.218; posting-account=5RIiTwoAAACt_Eu87gmPAJMoMTeMz-rn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20548 Date: 2008-03-22T10:16:21-07:00 List-Id: On Thu, 20 Mar 2008 22:17:18 +0000, Simon Wright wrote: > Why would things be different if there were rotations involved? On Mar 21, 1:52 am, "Dmitry A. Kazakov" wrote: > Because with rotations coordinates become linear combinations with > dimensionless coefficients. (The rotation matrix is a matrix exponent so > that cannot be made dimensioned.) The coordinates of the transformation matrix are indeed dimensionless (on balance, see below), but the coordinates of the vectors themselves can well be dimensioned. Doing it this way can require type conversions, but not always, depending on what operation the application of a rotation matrix represents. The two prototypical meanings of the mathematical expression are these: (1) dynamic motion of a vector within a single coordinate frame and (2) coordinate conversion of a vector between two overlapping coordinate charts (as with the definition of a manifold, among others). In the first application, there's no coordinate conversion. In the second, there is. The underlying mathematical computations are identical, yet significantly for a software implementation, the types of these operations are different. When dealing with multiple coordinate charts, the good reason to require chart-specific types is that coordinates change their meaning when transported from one coordinate frame to another. For example, if a coordinate pair represents a point, and the pair (1,1) represents point P in frame A, then (1,1) won't represent point P in frame B (except degenerately). So if you have a type Point, the right sort of declaration looks like this: type Point_in_A is new Point ; type Point_in_B is new Point ; package Convert_from_A_to_B is new Frame_Conversion( Domain => Point_in_A, Range => Point_in_B ) ; The package Frame_Conversion would contain all the necessary type conversions. Presumably it's an entirely pragma(Inline) library. Having said all this, a transformation matrix that converts between coordinate frames as above has units (meters in B)/(meters in A). On balance, this is dimensionless, but there are context-specific units hiding behind the scenes. Thus even declaring such a matrix should have a declaration that captures these types. The package Frame_Conversion is a natural source for such types toward this purpose. Eric