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-09 14:22:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Robert C. Leif, Ph.D." Newsgroups: comp.lang.ada Subject: RE: Dimensions (was Re: Another Idea for Ada 20XX) Date: Sun, 9 Dec 2001 14:15:38 -0800 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 1007936522 8502 137.194.161.2 (9 Dec 2001 22:22:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sun, 9 Dec 2001 22:22:02 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C118E95.B5F013C8@adaworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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:17655 Date: 2001-12-09T14:15:38-08:00 From: Bob Leif To: Richard Riehle, Nick Roberts et al. I am trying to find a free version of ABBET. ABETT has an approach to dimensions. The IEEE charges for a standard that they do not support and ship it as paper. I believe that this work was primarily done by Bill Whitaker. 1226.1-1993 IEEE ABBETa Trial-Use Standard for Common Ada Packages for A Broad-Based Environment for Test (ABBETa) 1993 1993/ Softcover /104pp List Price:$76.00 IEEE Member Price:$61.00 ISBN 1-5593-7360-1 IEEE Product No. SH16709-TBR Product Size: 8.5 x 11 IEEE Standard No.:1226.1-1993 Availability: Available to Ship I hope that in Richard Riehle's generic approach, that the Metric_Number into a record containing a into a Quantity and Units_Type. One approach is to declare the types of the acceptable units in terms of their exponents. Then addition-subtraction requires that the exponents match; and multiplication-division only adds or subtracts the exponents. The input, output, and checkpoints could be strongly typed to only include allowable combinations of the individual Unit_Exponents and quantities. Assertions could possibly be used for this checking. The hard part is to eliminate as much as is prudent of the exponent run-time type checking of the Units. Type Units_Exponents_Type is record Current_Exponent : Unit_Exponent_Type; Luminescense_Exponent : Unit_Exponent_Type; Temperature_Exponent : Unit_Exponent_Type; Mass_Exponent : Unit_Exponent_Type; Moles_Exponent : Unit_Exponent_Type; Length_Exponent : Unit_Exponent_Type; Time_Exponent : Unit_Exponent_Type; End Record; I might note that I would like to be able to make the quantity base 10. One can not easily do the equivalent of a decimal floating point type with type decimal. It is simpler to use units that have not be scaled for internal calculations. I wrote a package to use the correct prefix for output. type Prefix_Type is (Yotta, Zetta, Exa, Peta, Tera, Giga, Mega, Kilo, Hecto, Deka, No_Exp, Deci, Centi, Milli, Micro, Nano, Pico , Femto, Atto, Zepto, Yocto); -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Richard Riehle Sent: Friday, December 07, 2001 7:53 PM To: comp.lang.ada@ada.eu.org Subject: Re: Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist wrote: > "Richard Riehle" wrote in message > news:3C0EF0A0.9F42EDB4@adaworks.com... > > > > > package Metric_Number is > > type Metric_Type is private; > > -- export services for arithmetic on this type > > function "+"(L, R : Metric_Type) return Metric_Type; > > -- more arithmetic and boolean functions > > private > > -- full definition for the Metric_Type; > > -- helper type to avoid recursion during implementation > > end Metric_Number; > > I have no idea what you're getting at with the "helper type to avoid > recursion"... :-) In implementing the infix operators for an experimental version of this package, I found myself having to solve the problem of having the full definition of the type as a numeric type itself. > But in any case, the "good old-fashioned encapsulation" > isn't enough (see below)... > All these schemes that rely on hiding the representation have some serious > weaknesses. First of all, the public view is not scalar. So > > (a) your type is not compatible with generics that take scalar formals -- > you are limited to formal private types; and Granted. One would be required to write one's own versions of the generics and that would be a really bad idea. Once again, I experimented with this and ended up with some truly baroque code; workable but baroque. > (b) you cannot declare subtypes with range constraints. > (In my opinion (b) is by far the worse of these). Actually, I think (a) is worse than (b). One could define the package as generic and include generic formal parameters for the range constraints. > (c) it's way labor-intensive In experimenting with this idea, I found that I could factor out some properties to make it less labor-intensive than it might seem to be at first glance. Nevertheless, you are correct that it is more labor intensive than the more straigthforward approach orginally suggested. > But the worst is still to come :-). These schemes are quite brittle and > unscalable, because: > > (d) you have to define all your visibly quasi-numeric operations on every > combination of types for base and derived units, so you have a > multiplicative explosion on your hands In fact, I designed some generics to test this and found that the real problems are: 1) no notion of zero, 2) difficult to determine the 'Last and 'First, and 3) most other normally available attributes are not available. > (e) , (f), and (g) from your posting. I give you the points on those. My suggestion, however, does work for some situations. In experimenting with this idea, I decided to export the appropriate mathematical functions after instantiating the generic elementary functions within the body for the abstract number. I agree that the final numeric package is very specialized but it seems to have a small range of applicability for some circumstances. Meanwhile, I am experimenting with other options that might permit a solution without new language features. I will report on my findings if they are at all interesting. Richard Riehle