5 ms·

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

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.
      - jessaustin 12y ago
        Floating point is treated differently by compilers, involves different components of the processor, generates different types of errors, and has different performance. Perhaps there is some perspective from which that proposition is true?
        jjoonathan 12y ago
        A perspective where one is more familiar with IEEE754 than your in-house custom fixed-point implementation of choice? There are plenty of applications where it makes sense to do something different because you need to accommodate special hardware (e.g. FPGAs), because you want a different representation density/range, or because external policy effectively dictates the most natural format (e.g. finance). But in the absence of a pressing concrete reason to ditch 754 floats, they are BY FAR the best option for high performance, reproducible, portable, debuggable math with abundant documentation and pre-existing pools of expertise. They're far from trivial but so is the fixed-point code you would replace them with. If someone couldn't be bothered to learn the relevant intricacies of IEEE754, why do you expect them to do a better job re-implementing the stuff on top of integer math (or picking apart the in-house attempt to do so)? Shifting from problems of the "intern forgot to reset the rounding mode" variety to the "Newton's method code erroneously terminates one cycle too early if the last bit is a 1" variety hardly seems productive.
        12y ago
Ankaios 12y ago
The SI units absolutely include newtons and millinewtons. The derived units (http://physics.nist.gov/cuu/Units/units.html http://physics.nist.gov/cuu/Units/units.html) and prefixes (http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/prefixes.html) are both part of the SI. Also, remember, people are representing these numbers on computers. Derived units are very useful—in fact they are often critical to achieving necessary accuracies using compact representations. Further, representing quantities in terms of other unique, problem-specific units is often extremely helpful for ensuring good numerical behavior.

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.
    - jessaustin 12y ago
      Floating point is treated differently by compilers, involves different components of the processor, generates different types of errors, and has different performance. Perhaps there is some perspective from which that proposition is true?
      - jjoonathan 12y ago
        A perspective where one is more familiar with IEEE754 than your in-house custom fixed-point implementation of choice? There are plenty of applications where it makes sense to do something different because you need to accommodate special hardware (e.g. FPGAs), because you want a different representation density/range, or because external policy effectively dictates the most natural format (e.g. finance). But in the absence of a pressing concrete reason to ditch 754 floats, they are BY FAR the best option for high performance, reproducible, portable, debuggable math with abundant documentation and pre-existing pools of expertise. They're far from trivial but so is the fixed-point code you would replace them with. If someone couldn't be bothered to learn the relevant intricacies of IEEE754, why do you expect them to do a better job re-implementing the stuff on top of integer math (or picking apart the in-house attempt to do so)? Shifting from problems of the "intern forgot to reset the rounding mode" variety to the "Newton's method code erroneously terminates one cycle too early if the last bit is a 1" variety hardly seems productive.
      - 12y ago

Ankaios 12y ago

The SI units absolutely include newtons and millinewtons. The derived units (http://physics.nist.gov/cuu/Units/units.html http://physics.nist.gov/cuu/Units/units.html) and prefixes (http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/prefixes.html) are both part of the SI. Also, remember, people are representing these numbers on computers. Derived units are very useful—in fact they are often critical to achieving necessary accuracies using compact representations. Further, representing quantities in terms of other unique, problem-specific units is often extremely helpful for ensuring good numerical behavior.