Re: [boost] [units] Crazy idea/question

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-02-16 16:23:33

On 2/16/07, Deane Yang <deane_yang_at_[hidden]> wrote:
> Yuck. Please forgive me for stepping into the middle of this discussion
> without having read any of the previous discussion carefully (I have
> been scanning all of the messages as they were posted), but the fact
> that this discussion is even taking place makes me feel like everyone is
> going down the wrong path.
>
> Does anyone really have software with code like
>
> ( 1.0 * SI::meters + 1.0 * imperial::feet ) * ( 2.0 * CGS::centimeters +
> 1.0  * imperial::feet )

Not exactly like that no, but I can say that I have software that
definitely deals with mixed units.  Units that do not come from code,
but come from a database.  Changing those databases would break all of
the software that uses them, so that's not an option.  As a quick
example, here are some of the types of data plus their units:

Terrain elevation : meters
Aircraft altitude : feet
Radar range : nautical miles
Radar max ceiling : feet
Radar beam angle : degrees (I only listed this because mcs::units includes it)
Atmospheric Refractivity Index : unitless

> Does anyone really want a library that makes this possible?
>
> I'm far from an expert in software engineering. Nor do I know exactly
> what others are using the dimension/units library for. But the last
> thing I want is a library that allows code like this.
>
> Let me try to make some points (which I concede are totally self-centered):
>
> 1) To me, the purpose of such a library is *not* to be able to mix
> different units of the same dimension inside a single expression. I'm
> sorry, but I feel that the existence of an arithmetic expression with
> different units for the same dimension is a clear sign of poor software
> design. I would certainly redesign my code to eliminate anything like
> this. There are just too many possible pitfalls.

One example I can think of is getting the height of a radar beam,
given a range and a beam angle.  The common one is (I've factored out
the beam angle, assume it's 0):

h = R^2 / 2ka

where h is the height, R is the range, k is the refractivity (commonly
the 4/3 Earth model), and a is the Earth's radius.

That formula assumes that R and a are both in the same unit system,
and consequently h will be given in that unit.

Now in my case, R would be given in nautical miles, Earth's radius
would be given in meters, and I would want h to be in feet so that I
could compare it against an aircraft's altitude.  For me to use that
formula, I would need unit conversions somewhere, presumably
immediately after extraction from the database, and then all code
henceforth would use one unit system.

But there exists a formula that approximates the same thing, only it
takes in R as nautical miles, and returns h in feet?

h = (R / 1.23)^2

where R is in nautical miles, and h is returned in feet.  That formula
is much better for me, since all of the radar ranges are given in
nautical miles, and all of the aircraft altitudes are given in feet.
The difference between the two is usually under 80 feet.

Across unit system operations/comparisons seems really neat to me, but
I'm unsure of the ramifications.  Surely you are no longer in the
compile-time only world?  I'm happy enough with what Matthias has done
so far, but supporting that would be really cool I think.

E.g. for me, it would be really nice to compare the aircraft's height
to the ground elevation (to make sure we're not flying into a
mountain) without doing a unit conversion first, since aircraft
altitude is always given in feet, and ground elevation in meters.
This is definitely run-time support though.

I think the difference is that the current system will guarantee
safety by not compiling the following, while the run-time units would
guarantee safety by allowing it to compile and doing the correct
conversions behind the scenes:

// maintain a certain altitude above ground level
if (aircraft.altitude > ground_elevation + min_agl_offset)
{
   // ...
}
else
{
   // ...
}

I see both as enormously useful, the compile-time one as required, and
the run-time support as optional.

--Michael Fawcett