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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d303864ae4c70ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-14 00:10:35 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: Expressing physical units (Was: Reprise: 'in out' parameters for functions) Date: 14 Apr 2004 00:10:35 -0700 Organization: http://groups.google.com Message-ID: References: <5ad0dd8a.0404090512.15af2908@posting.google.com> <5ad0dd8a.0404100507.729d3577@posting.google.com> NNTP-Posting-Host: 63.194.87.148 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1081926635 29727 127.0.0.1 (14 Apr 2004 07:10:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 14 Apr 2004 07:10:35 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:7071 Date: 2004-04-14T00:10:35-07:00 List-Id: "Dmitry A. Kazakov" wrote in message news:... > Russ wrote: > > > "Dmitry A. Kazakov" wrote in message > > news:... > >> Russ wrote: > >> > >> > By the way, I work in the field of air traffic management (ATM), and > >> > I'd really like to see a practical way to guarantee units consistency. > >> > The general mks system is inappropriate for ATM. The traditional units > >> > for ATM are nautical miles (nmi) for horizontal length, and feet (ft) > >> > for altitude. That won't change in our lifetimes -- and probably > >> > never. As for time, it can be in seconds, minutes, or hours. > >> > Horizontal speed in usually given in terms of knots (kn), which is > >> > nmi/hr, but altitude rate is usually given in terms of ft/min. Heading > >> > is normally given in degrees. > >> > > >> > In my experience, the most common units problem is confusion between > >> > degrees and radians. Radians are preferable for use inside programs, > >> > but degrees are preferable for I/O. This problem really needs to be > >> > licked once and for all. > Now to templates and C++. You are wrong thinking that units can be properly > done in C++. What indeed can be, is a tiny part of what is really > necessary. Consider the following issues: > > 1. Shifted units, like Celsius degree. > 2. Dealing with units unknown at compile time. How would you communicate > with a data base, or develop a gauge widget, or write a unit calculator? > How to write a unit I/O package? > 3. Dealing with multiple unit systems. The C++ solution actually works in > SI. It means that a measure in [ft] has to be converted to [m]. It is OK as > long as: > 3.a. There is no range problems. In an emedded system one could use a fixed > arithmetics with would overflow if the distance is measured in [m], but > work fine for [km]. > 3.b. One can ignore inevitable precission loss caused by unit conversions. > This might be critical for some applications. > 5. How to handle logarithmic units and other non-linear scales? > 6. Container problem. Surely a vector, matrix etc of dimensioned values > should have a dimension. Possibly it could be handled by templates, but I > am afraid it would not be so easy. > 7. Any generic (template) solution would make everything based upon it also > generic. You're talking about the Grand Unified system of units. That's fine, but I'm just talking about something that can make air traffic management (ATM) software more robust. As I wrote before, the most important units in ATM are few in number. Here is an outline of what I was working on in my free time before my hard drive died. You define a dozen or so Ada types for commonly used units, such as nmi (nautical miles) feet FL (flight level, or 100 ft) kft (1000 ft) deg rad (radian) knots fpm (feet per minute, for altitude rate) klb (1000 pounds) sec (second) minute hour and perhaps a few others. You then define operators for all the likely operations among these types. Each type can be added to or subtracted from its own type, for example. When you divide a type by the same type, you get a dimensionless number. Multiplication of like types is prohibited unless it really makes sense. If you divide nmi by hour, you get knots. If you divide nmi by sec, the compiler coughs and tells you that you can't do that -- so you go and convert the seconds to hours (using a predefined conversion function). You get the idea. As new units or combinations come up, you add them into the repertoire. Perhaps the total number of units and reasonable combinations would be managable. The idea here is not to have all units converted automagically but rather simply to have the compiler catch any potentially inconsistent use of units. The days of using degrees for radians, or dividing nmi by sec and adding it to knots, would be mercifully over. And no generics are needed. Is this a reasonable approach?