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

[18k11tm001@sneakemail.com (Russ)]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<ij2ec.22694$1y1.20221@nwrdny03.gnilink.net>...
> 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.