Re: Expressing physical units (Was: Reprise: 'in out' parameters for functions)

From: Russ (18k11tm001_at_sneakemail.com)
Date: 04/14/04

  • Next message: Martin Krischik: "Re: Unified Ada library" 
    Date: 14 Apr 2004 00:10:35 -0700

    "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<c5gh04$1ba02$1@ID-77047.news.uni-berlin.de>...
    > Russ wrote:
    >
    > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
    > > news:<c5dr33$gkic$3@ID-77047.news.uni-berlin.de>...
    > >> 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?

  • Next message: Martin Krischik: "Re: Unified Ada library"

    Relevant Pages

    • Re: Expressing physical units (Was: Reprise: in out parameters for functions)
      ... Dealing with units unknown at compile time. ... If you divide nmi by sec, the compiler coughs and tells you ... I only do not see any reason why it should make any sense in ...
      (comp.lang.ada)
    • Re: Teaching new tricks to an old dog (C++ -->Ada)
      ... attributes helps both the writer and the compiler. ... > catch at compile time any out of boundaries access. ... C++ array like types don't have these properties. ... Maybe, if one gets used to template programming, the basis of the ...
      (comp.lang.ada)
    • Re: Teaching new tricks to an old dog (C++ -->Ada)
      ... attributes helps both the writer and the compiler. ... > catch at compile time any out of boundaries access. ... C++ array like types don't have these properties. ... Maybe, if one gets used to template programming, the basis of the ...
      (comp.lang.cpp)
    • Re: Is there a better way?
      ... I can freely modify the contents of foo, ... Part of the issue is that C doesn't really have the full language ... Processing done by C at compile time is ... the interpreter and the compiler are permitted to ...
      (comp.lang.lisp)
    Loading