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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ec68713820981fe9,start X-Google-Attributes: gid103376,public From: William A Whitaker Subject: SI Units Solicitation - Upgrade from comments Date: 1997/08/21 Message-ID: <33FBD411.3B4A@erols.com>#1/1 X-Deja-AN: 265652325 Reply-To: whitaker@erols.com Organization: Erol's Internet Services X-Received-On: 21 Aug 1997 05:38:24 GMT Newsgroups: comp.lang.ada Date: 1997-08-21T00:00:00+00:00 List-Id: "... a decent respect to the opinions of mankind requires that they should declare the causes which impel them ..." This is an interim report on the responses to the Solicitation of comments on a SI Units proposal for IEEE P1446, Ada-Based Test Program Development. I wish to thank those who provided comments. Addition/further/new comments are invited. The revised proposal is given, with links to code, in http://www.erols.com/whitaker/iss_418.htm A full accounting of comments is given in http://www.erols.com/whitaker/si_cmts.txt Two general statements: First, the example given was abstracted, with very little modification, from code used in IEEE P1446, which left a few footprints (e.g., there was a subtype Number which was left over and has now been removed). For the P1446 standard, it is important that it be concrete and allow only the use of the numeric type Real, defined elsewhere. As a general Ada facility, it is proper that it be generic. A rephrasing of the example as a generic looks a bit strange, but is given in http://www.erols.com/whitaker/si_gen.txt As an Ada facility, it is probably important to group the operations with the Unit type definition for derivability (deriving is not encouraged in P1446, but then "possible" is not "required"). This has been done, requiring the additional "use type SI.Unit" in code, although I was rather hoping to reduce the number of with/use in code. Second, the driving force of the proposal was to find a method of units checking in Ada that would be acceptable/comfortable to ordinary engineers. If it was not fairly invisible, it would never be used. The gimmick of naming the unit subtypes and the conversion functions the same is considered important to that goal and drives the packaging. Direct literals are not possible, this was the closest I came. The solution of packaging everything together and calling the conversions To_Meter, To_Second, ... was used 5 years ago and was rejected by users at that time. Other changes include: Spellcheck has been run on the text. subtype Dimensionless has been redesignated Null_Unit. There is possible confusion surrounding the word "dimension". Function Nth_Root - a unique need for Unit. Other observations: On reflection, many 'Attributes would have no meaning for Unit. Meter'First could only be an artificial flag. Unit'First has no meaning at all. Unit_Power could be restricted to 127, or less in some cases. This was done in 1226. But the only real advantage would be (following an early suggestion by Leif) to encode the whole set of Unit_Powers in a single 32-bit integer, thereby allowing a smaller structure and literals for the Power. Is there any interest in this modification? Run-time costs are probably minimal in this day, and can be cut off by using the non-checking version. But there is one situation in which this is not true, large compute/memory limited physics calculations with large unit-ed arrays. Straightforward implementation would make an array of Meter an array of type Meter. For efficiency, one could rather have a Meter_Array, a unit-ed type which has as Value an array of Real (and the appropriate operations).