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

[18k11tm001@sneakemail.com (Russ)]

"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?