Michael Fawcett wrote:
On 2/16/07, Deane Yang <deane_yang@yahoo.com> 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.