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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Russ wrote:

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

Yes.

> 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.

AFAIK, ATM does not much differ from other MMI. For them run-time unit
checking fits at best, because performance/space requirements are not that
strict.

Here is my implementation:

http://www.dmitry-kazakov.de/ada/units.htm

> 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 do not need that much of types. Internally you should work in SI units.
The only place where units appear is MMI readings and controls. A usual way
is to make widgets unit aware and tunable at run time. Here your problems
end. The operator will use ft, m, km, lightyear, whatsoever. It is the
widget property. The result will be always in the corresponding SI unit.

> 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.

Yes, you are trying to keep several unit system separate. Like meter-second,
knot-hour etc. I only do not see any reason why it should make any sense in
your case.

> 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.

You want to manage a geometric explosion...

> 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.

Dividing miles by seconds has a clear physical sense.

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

It is a possible approach, but I think that for your case run-time checks
are more suitable (for MMI). Only if you have some additional safety
requirements, explicitly stating that all formulae shall be statically
checked, then you can additionally use a compile-time approach, see:

http://home.T-Online.de/home/Christ-Usch.Grein/Ada/Dimension.html

But in any case, you have to switch to SI. Then 80% of your problems will
disappear.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de