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-09 11:08:49 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-2-47.cvx6.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: Sun, 9 Dec 2001 17:58:14 -0000 Message-ID: <9v0crt$bo2bi$1@ID-25716.news.dfncis.de> References: <11bf7180.0112070815.2625851b@posting.google.com> NNTP-Posting-Host: ppp-2-47.cvx6.telinco.net (212.1.135.47) X-Trace: fu-berlin.de 1007924926 12323186 212.1.135.47 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:17648 Date: 2001-12-09T17:58:14+00:00 List-Id: I'm liking this idea a lot! Supposing the revision adds a package: package Ada.Units type Unit_Type is private; Unitless : constant Unit_Type; Meter : constant Unit_Type; Kilogram : constant Unit_Type; Second : constant Unit_Type; Ampere : constant Unit_Type; Kelvin : constant Unit_Type; Mole : constant Unit_Type; Candela : constant Unit_Type; function Is_Unitless (The_Unit: in Unit_Type) return Boolean; function "*" (Left, Right: Unit_Type) return Unit_Type; function "/" (Left, Right: Unit_Type) return Unit_Type; function "**" (Left: Unit_Type; Right: Integer) return Unit_Type; function "*" (Left: Unit_Type; Right: universal_real) return Unit_Type; function "*" (Left: universal_real; Right: Unit_Type) return Unit_Type; function "/" (Left: Unit_Type; Right: universal_real) return Unit_Type; function "/" (Left: universal_real; Right: Unit_Type) return Unit_Type; end Ada.Units; We can declare our own units, e.g.: Foot: constant Ada.Units.Unit_Type := Meter * 0.3048; Then we can declare a 'unit-specific' (fixed-point) type: type Accelerometer_Reading is delta 0.02 range -4.7 .. +4.7 unit Foot/Second**2; This form has the problem of introducing a new reserved word ("unit"), but I feel this is more appropriate, since the unit is an aspect of the 'key abstraction' of the type (rather than just a matter of implementation or checking). Fixed-point types could nevertheless have an attribute Unit (with the special dispensation for reserved words accorded Range etc). If we then declared e.g.: type Acceleration is delta 0.01 range -50.0 .. +50.0 unit Meter/Second**2; Reading: Accelerometer_Reading; Rate_of_Ascent: Acceleration; we could convert from one type to another the normal way: Rate_of_Ascent := Acceleration(Reading); which would cause a scaling multiplication (if necessary). Furthermore, view conversions work perfectly: procedure Adjust_for_Wind (RoA: in out Acceleration); ... Adjust_for_Wind(Acceleration(Reading)); The appropriate scaling is performed for the variable Reading on the way in and (the inverse scaling) on the way out. Possibly one advantage of this scheme is that a compiler could opt out of doing the dimension checking without causing any problem (other than the actual lack of checking, of course!). The standard type Duration could be declared: type Duration is delta ... range ... unit Ada.Units.Second; Fixed-point types without the 'unit' part in the declaration would default to being 'unitless'. Predefined operations between a unitless fixed-point type and a unit-specific one would work as currently, with no dimension checking, and the reult would also be unitless. This would be vital for maintaining code continuity, of course, but also I suspect that unitless fixed-point types would continue to have a vital role as intermediary types for calculation and other processing. I don't believe unit specification (and therefore dimension checking) is applicable to floating-point types. They may be used for various purposes (perhaps often when a fixed-point type ought to be used), but a floating-point number is conceptually a ratio, and therefore implicitly unitless (and dimension-indeterminate). If they are used for intermediate calculations, that's too bad (a good programmer will take extra precautions if practicable). There's the question of private types. I feel that the requisite conversions and other mixed operations should be provided for a private type explicitly (in its package spec), and that these operations should do the requisite conversion and checking, which may well be more complicated than mere scaling and dimensionality. The unit facilities would, of course, be applicable to those components which were of unit-specific (fixed-point) types. Three further notes need to be made. (1) I am not sure if the (seven) SI units I have presented are the complete set of basic units required in reality. (2) Dimensional analysis could extend (from the basic MLT) to temperature, amount of matter, and electrical current. But I don't know if it would be practical for these 'extra' dimensions (or any others) to be included in the checking. (3) I have not provided for units that are offset from the SI units' zero points (which are presumably all at the corresponding 'physical' zero point). I believe some other post suggested that this tends to be a fairly cosmetic matter anyway. -- Best wishes, Nick Roberts