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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-14 23:11:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Steven Deller" Newsgroups: comp.lang.ada Subject: RE: Dimensionality Checking (Ada 20XX) Date: Sat, 15 Dec 2001 02:07:41 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1008400263 38544 137.194.161.2 (15 Dec 2001 07:11:03 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sat, 15 Dec 2001 07:11:03 +0000 (UTC) Cc: To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3c19c13f.3311687@News.CIS.DFN.DE> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:17947 Date: 2001-12-15T02:07:41-05:00 What is wrong with using Pat Roger's dimensioning system. It has units and scaling. It allows making metric, English, or other dimensional units, with all "interconversions" straightforward and easy. For example, the following user code works with dimension checking and appropriate scaling conversions: ================================================================== -- (C) Copyright 1998 by Patrick Rogers of Software Arts & Sciences -- progers@classwide.com -- http://www.classwide.com -- -- Rights to use, distribute or modify this package in any way is hereby -- granted, provided this header is kept unchanged in all versions. -- Additionl headers may be added. If you make a valuable addition, -- please keep us informed by sending a message to progers@classwide.com -- -- THIS ADA LIBRARY IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED -- WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF -- MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. with Float_Units; with Metric_Float_Units; with Ada.Text_IO; procedure Test_Metric is use Float_Units, Metric_Float_Units; M : Mass := 1.0 * Kilogram; E : Erg := M * C**2; begin Ada.Text_IO.Put( Float'Image( Value_of(E) ) ); end Test_Metric; ================================================================ This seems very powerful, easy to use, and readable. Mass is just a subtype of Unit with fixed discriminants. Kilogram is just a Mass with a specific magnitude. "Unit"s are discriminated records with a single float magnitude. The "Dimensioned Units" is a generic package (generic with respect to the magnitude type) and defines all *operations* that units can participate in (add, multiply, exponent to an integer, and so on). The "system" of units (e.g. MKS or CGS or English or ...) is independently defined as a generic that takes a package that is some instance of the units package. It is in such a "system" where units are defined. The whole thing looks like the PERFECT abstraction of the issues and has appropriate separation of concerns. As many people have pointed out, the dimensions in the discriminants (of the implementation) are constants and the intermixings involve simple integer operations, so a smart compiler could collapse all discriminant operations and do all dimension validation during compilation (e.g. WARNING: This operation will always raise Dimension_Exception). A compiler could even do away with any explicit storage of the discriminants because they are *always* "constant" (when constants are collapsed) so storing them is just redundant. Not that any compilers do so yet ... but it seems as easy to do as implementing some "units checking scheme yet to be invented" and the optimizations would have a more general applicability. Not sure where to pick up Pat Roger's stuff on the net. If you can't find it and want it, let me know. Of course, for 7 dimensions, you will have 7 discriminants (all constants of some integer type), but it seems to me that such information would be needed in any case. I'd guess that storing dimensions as 8-bit integers would be more than enough -- I can't think of any sensible unit's system that needed more than about plus or minus 4 or so multiples of a given dimension. A 16-byte record could hold up to 8 dimension discriminants, along with a high-precision float. Of course all these should be generic. The only difficulties I see are getting the RIGHT system of dimensions for such a package (but then again, not being "built in", it can be changed is so needed). Regards, Steve Deller