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-11 23:58:12 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: 11 Apr 2004 23:58:12 -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 1081753092 31812 127.0.0.1 (12 Apr 2004 06:58:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 12 Apr 2004 06:58:12 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:6991 Date: 2004-04-11T23:58:12-07:00 List-Id: Hyman Rosen wrote in message news:... > Jacob Sparre Andersen wrote: > > It should be noted that my analysis was tied rather strongly to Ada, > > and a more relaxed programming language might be able to do something > > that would be sufficiently close to full compile-time unit checking. > > C++ can do full compile-time unit checking with no runtime overhead > as long as all units needed by the program are known at compile-time. > The technique uses templates, requires automatic instantiation of > templates for usability (and so cannot be done in Ada), and was published > in Barton & Nackman, _Scientific and Engineering C++_. I've often posted > the technique, but here goes again, in a simplified version: Just for my own education, would you mind explaining why it cannot be done in a usable way in Ada? Is it because you need a sizable chunk of instantiation code at the top of each source file that is to use it? If so, isn't there some trick to get around it? 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. The next most common problem I find is that altitude is alternately expressed in terms of ft, hundreds of ft, or thousands of feet. Standard "Flight Levels" are at multiples of 1000 ft, but they are expressed in units of 100 ft. For example, "FL310" is a pressure altitude of 31,000 ft. If a practical way could be developed to deal with these basic units, and perhaps a few others (such as weight), the integrity of ATM software could be enhanced considerably, I believe. I was working on a scheme a couple of years ago involving the standard Ada type system, but I was (and still am) an Ada programming newbie. I think it would have worked reasonably well, but who am I to say? In any case, my friggin' hard drive died and I didn't have that particular work backed up, so its gone.