4 ms·

It's common for pretty much all of engineering really. It's ludicrous to make calculations a bit more complicated by using weird non-SI units. The fact that NA

It's common for pretty much all of engineering really. It's ludicrous to make calculations a bit more complicated by using weird non-SI units. The fact that NASA managed to crash a probe into Mars because they hadn't yet learned the lesson says it all really. Just use SI units and stop worrying about it.

thenmar 12y ago
If anyone is curious, it looks like it was the fault of Lockheed. NASA's contract specified SI units: http://en.wikipedia.org/wiki/Mars_Climate_Orbiter http://en.wikipedia.org/wiki/Mars_Climate_Orbiter
Ankaios 12y ago
No, the important lesson is to always label your units, and another one might be to always be careful passing dimensionful numbers between codes and teams. You can run into the same problem by accidentally even forgetting to convert between, e.g., newtons and millinewtons.
- lotsofmangos 12y ago
  Even if you label your units, you get conversion errors that can easily multiply up into something nasty that goes boom.
- Tloewald 12y ago
  SI units don't include millinewtons, so the problem wouldn't arise. That's part of the point. You measure mass in kg, not g, not tonnes. You measure distance in metres. Not kilometers. Not nautical miles. You measure time in seconds. A Newton is a derived SI unit — 1 kg m / s^2 Incidentally, this is why engineering notation works the way it does. You pick your units and you get the significant figures from the mantissa and the descriptive prefix (giga, nano, micro, kilo, etc.) from the exponent.
  - pimlottc 12y ago
    His point (I believe) is you always need to label units regardless of system. You could have the same problems with microseconds vs nanoseconds.
    - jjoonathan 12y ago
      Tloewald's point was that microseconds and nanoseconds are not SI base units, so standardizing on base units eliminates the ambiguity (the second alone is the SI base unit of time). Of course additional mechanisms of double and triple checking are probably still warranted to account for human fallibility.
      - pimlottc 12y ago
        Regardless of what you standardize, you still need to include the unit for any figure.
        Tloewald 12y ago
        Yes but you eliminate errors when working within a type of unit. NASA's problem came from converting one kind of length to another. You are clutching at straws here.
      - jessaustin 12y ago
        That's fine until you start using floating point values in order to satisfy this SI fetish. (I guess you like farads and henries too.) It's much better to use fixed point and keep track of your multiplier. A sufficiently advanced type system could do this, but at some point it will require careful thinking about precision.
        Tloewald 12y ago
        Using fixed point and tracking your multiplier is exactly like using floating point.
- tjradcliffe 12y ago
  That is precisely the policy adopted by NASA, and it lead to the Mars disaster, so you are suggesting as a solution the exactly policy that caused the problem. Furthermore, you are suggesting that the same entities--highly trained engineers and scientists and project managers--that proved inadequate to follow the policy you are suggesting last time can somehow be expected to follow the policy correctly at all times in the future. Reducing needless complexity--in this case by enforcing a standard of common units so that when the inevitable inevitably occurs and someone forgets to label things--there is a much reduced (but still non-zero) chance of undetected mis-matches occurring. Furthermore, it is very difficult to confuse milli-newtons with newtons even if a project was for some reason using both, because they differ by three orders of magnitude, which tends to get noticed. Whereas kilograms and pounds differ only by a factor of 2.54, which might be--and in fact has been--missed.
  - Ankaios 12y ago
    Are you seriously claiming that a policy of labeling and testing units caused MCO to be lost? Have you actually studied the mishap? If labeling and verifying the units was done carefully it would have prevented the accident. A millinewton/newton mix-up could easily occur in a case like this one, too. The particular numbers which were misinterpreted in MCO's case were often small, and I can easily believe no one noticing similar ones being a few orders of magnitude off. (I do have a hard time imagining it with MCO's particular numbers, though.) Similarly, you can be bitten by a meters/centimeters switch or accidentally using different representations of the same quantity, such as specific impulse and its corresponding characteristic exhaust velocity, which only differ by a factor of about 10 when both are expressed in SI units. I maintain that the key lesson is to always label your units, and to test them carefully and routinely, including at interfaces. I believe that claiming that using English units (as gross as they often are) caused the failure misses the more fundamental root problem. (Also, I'm not claiming that labeling and verifying units is easy. I emphasize it partly because it's hard. Little of our current software ecosystem includes any concept of dimensionful numbers.)
bfe 12y ago
It's Lockheed Martin that still insists on using imperial units instead of SI, even after the loss of mission that confusion caused in their work with metric-using JPL on Mars Climate Orbiter.

thenmar 12y ago

If anyone is curious, it looks like it was the fault of Lockheed. NASA's contract specified SI units: http://en.wikipedia.org/wiki/Mars_Climate_Orbiter http://en.wikipedia.org/wiki/Mars_Climate_Orbiter

Ankaios 12y ago

No, the important lesson is to always label your units, and another one might be to always be careful passing dimensionful numbers between codes and teams. You can run into the same problem by accidentally even forgetting to convert between, e.g., newtons and millinewtons.

lotsofmangos 12y ago
Even if you label your units, you get conversion errors that can easily multiply up into something nasty that goes boom.
Tloewald 12y ago
SI units don't include millinewtons, so the problem wouldn't arise. That's part of the point. You measure mass in kg, not g, not tonnes. You measure distance in metres. Not kilometers. Not nautical miles. You measure time in seconds. A Newton is a derived SI unit — 1 kg m / s^2 Incidentally, this is why engineering notation works the way it does. You pick your units and you get the significant figures from the mantissa and the descriptive prefix (giga, nano, micro, kilo, etc.) from the exponent.
- pimlottc 12y ago
  His point (I believe) is you always need to label units regardless of system. You could have the same problems with microseconds vs nanoseconds.
  - jjoonathan 12y ago
    Tloewald's point was that microseconds and nanoseconds are not SI base units, so standardizing on base units eliminates the ambiguity (the second alone is the SI base unit of time). Of course additional mechanisms of double and triple checking are probably still warranted to account for human fallibility.
    - pimlottc 12y ago
      Regardless of what you standardize, you still need to include the unit for any figure.
      - Tloewald 12y ago
        Yes but you eliminate errors when working within a type of unit. NASA's problem came from converting one kind of length to another. You are clutching at straws here.
    - jessaustin 12y ago
      That's fine until you start using floating point values in order to satisfy this SI fetish. (I guess you like farads and henries too.) It's much better to use fixed point and keep track of your multiplier. A sufficiently advanced type system could do this, but at some point it will require careful thinking about precision.
      - Tloewald 12y ago
        Using fixed point and tracking your multiplier is exactly like using floating point.
tjradcliffe 12y ago
That is precisely the policy adopted by NASA, and it lead to the Mars disaster, so you are suggesting as a solution the exactly policy that caused the problem. Furthermore, you are suggesting that the same entities--highly trained engineers and scientists and project managers--that proved inadequate to follow the policy you are suggesting last time can somehow be expected to follow the policy correctly at all times in the future. Reducing needless complexity--in this case by enforcing a standard of common units so that when the inevitable inevitably occurs and someone forgets to label things--there is a much reduced (but still non-zero) chance of undetected mis-matches occurring. Furthermore, it is very difficult to confuse milli-newtons with newtons even if a project was for some reason using both, because they differ by three orders of magnitude, which tends to get noticed. Whereas kilograms and pounds differ only by a factor of 2.54, which might be--and in fact has been--missed.
- Ankaios 12y ago
  Are you seriously claiming that a policy of labeling and testing units caused MCO to be lost? Have you actually studied the mishap? If labeling and verifying the units was done carefully it would have prevented the accident. A millinewton/newton mix-up could easily occur in a case like this one, too. The particular numbers which were misinterpreted in MCO's case were often small, and I can easily believe no one noticing similar ones being a few orders of magnitude off. (I do have a hard time imagining it with MCO's particular numbers, though.) Similarly, you can be bitten by a meters/centimeters switch or accidentally using different representations of the same quantity, such as specific impulse and its corresponding characteristic exhaust velocity, which only differ by a factor of about 10 when both are expressed in SI units. I maintain that the key lesson is to always label your units, and to test them carefully and routinely, including at interfaces. I believe that claiming that using English units (as gross as they often are) caused the failure misses the more fundamental root problem. (Also, I'm not claiming that labeling and verifying units is easy. I emphasize it partly because it's hard. Little of our current software ecosystem includes any concept of dimensionful numbers.)

bfe 12y ago

It's Lockheed Martin that still insists on using imperial units instead of SI, even after the loss of mission that confusion caused in their work with metric-using JPL on Mars Climate Orbiter.