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

From: Deane Yang (deane_yang_at_[hidden])
Date: 2007-02-16 16:47:41

Michael Fawcett wrote:
> 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
> 

<snip>

> 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.
> 
<snip>
> 
> // maintain a certain altitude above ground level
> if (aircraft.altitude > ground_elevation + min_agl_offset)
> {
>    // ...
> }
> else
> {
>    // ...
> }
> 

Ah, the dumb mathematician (me) finally gets it. The thing I never saw 
before is "aircraft.altitude". The point is that the different 
quantities (of the same dimension) come from member data of different 
objects, so they're all in different units. And now you want to compare 
or add them together.

I'd still use explicit casts to put everything into the same set of 
units (I like to be able to see explicitly what's going on), but I 
definitely have to concede that a reasonable desire is to have the 
conversions be done automatically and behind the scenes.

I would still prefer to write something like

if (aircraft.altitude > ground_elevation + min_agl_offset)

as

if (unit_cast<elevation_type>(aircraft.altitude) > ground_elevation + 
min_agl_offset)

So I know and can see easily that what units the computation takes place 
in. If you have a clever dimensions library that handles everything 
without explicit casting, then you don't know what units the computation 
uses. Admittedly, this is probably a misplaced worry of mine, but I can 
certainly envision some kind of iterative computation, where mixing the 
wrong units and having the library make a bad (unseen) choice of units 
to do the computation leads to invalid results. I have a strong aversion 
to hidden choices and effects like this.