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