5 ms·

The biggest lessons learned on the Mars Climate Orbiter wasn't exactly that everything should be metric. It was the unit conversion is dangerous and needs to be

The biggest lessons learned on the Mars Climate Orbiter wasn't exactly that everything should be metric. It was the unit conversion is dangerous and needs to be handled very carefully. Just saying everything will be metric doesn't avoid unit conversion. You might have one thing measuring fuel burn rate in grams/second and another in kg/second. That conversion can still lead to issues if not handled correctly. In the context of the space shuttle it was all designed in imperial units starting in the 70s so it would be very risky to convert everything to metric.

fnordpiglet 4y ago
I mean what issues would power of 10 fractions have in floating point after all?
- sbradford26 4y ago
  If I have data going out on a data bus in grams/second, but someone reading that data in a different sub system reads it and thinks it is kilograms/second because that is the default unit they use then you have an issue. The actual conversion of the bits isn't the issue it is that certain systems might use different units internally and making sure those conversions are done correctly. It is much more an engineering design/human interaction issue than a computation issue.
  - fnordpiglet 4y ago
    Yes, I understood that. However repeated conversions can lead to rounding errors such as catastrophic cancellation. This is even more esoteric than “grams here kilograms there” and thus easier to fall prey to. Depending on how precise your measurements are you could easily drop significant digits or add random noise, especially if you do large scale changes. https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...
    - sbradford26 4y ago
      Yeah we tended to utilize fixed point for many of our variables and documented the precision for each one. Then an analysis was done verifying that we were maintaining precision through the calculations from input from a sensor to output.
      - fnordpiglet 4y ago
        The problem is almost nothing today accelerates fixed point and everything supports floating point accelerations, which will speed up your ability to calculate the wrong number by many orders of magnitude.
        sbradford26 4y ago
        Yeah that makes sense. In aerospace they will fall on the side of accuracy even at the expense of speed. But they also tend to utilize FPGAs that can be designed to handle fixed point calculations quickly but with that comes a lot of cost and specialty hardware.
        fnordpiglet 4y ago
        Another place it makes issues is financial modeling, particularly for complex derivatives where the model might be extremely complex and small errors can accumulate into meaningful errors in risk calculations. Fixed point is sometimes used in finance but performance is also a real concern. There’s a lot you can do to reduce fp errors if your numerical libraries are carefully constructed. But it has often made me wonder why there aren’t processor lines with high performance fixed point since the math is extremely easy - even by just shifting the mantissa and working in integer space then shifting it back.
  - Merad 4y ago
    Pretty sure GP was making a sarcastic comment referencing how floating point is notorious for subtle rounding issues when handling values that have an exact representation in base 10 but a repeating pattern in binary.
    - fnordpiglet 4y ago
      Yeah. Given we’ve moved from counting on our fingers to counting on our computers we need a new base 2 metric.
chriswarbo 4y ago
> You might have one thing measuring fuel burn rate in grams/second and another in kg/second This sort of redundancy is a big problem with metric (e.g. hours, litres, tonnes, etc.); and why it's better to stick to the SI subset. http://www.chriswarbo.net/projects/units/improving_our_units.html#problems-with-metric http://www.chriswarbo.net/projects/units/improving_our_units... In particular, SI is "coherent" https://en.wikipedia.org/wiki/Coherence_(units_of_measurement) https://en.wikipedia.org/wiki/Coherence_(units_of_measuremen... - There is only one unit for each dimension. In your example, "grams/second" would not be a valid unit; SI only has kilograms/second (yes, it's annoying that the unit of mass has a name beginning "kilo" :( ) - The conversion factor between different dimensions is exactly 1 (by definition). In your example, the rate R is related to mass M and time T via M = TR (i.e. kilograms = seconds × kilograms/second). There are no conversion factors, since the unit of rate is derived from the units of time and mass (unlike, say, measuring energy as calories OR pound-feet OR coulomb-volts OR ounce-miles OR slug-acres-per-squared-hour OR ...) See also http://www.chriswarbo.net/projects/units/metric_red_herring.html#metric-conversions-multiply-by-one http://www.chriswarbo.net/projects/units/metric_red_herring....
- sbradford26 4y ago
  When designing new systems it is best to clearly define the expected units for everything clearly at the start. SI units are great but sometimes they are not great for the specific use case. When measuring high power systems like power plants or EVs kW/MW/GW are a more appropriate unit versus Watts. In embedded systems you have limited bandwidth having to have large variables just to store values in SI units is a waste versus using an appropriately scaled unit and saving bandwidth. Overall the conversion of the unit isn't the root of the issue. Clearly defining the data types and units of everything is the key issue. This makes sure any conversion is done when necessary and allows people to design systems so that they can avoid conversion if possible.
  - numpad0 4y ago
    INT_MAX is usually 2147483648, which means a "power" figure in Watt can handle anything from a laptop CPU to a Chernobyl power plant. FLT_MAX and _MIN are e+38 and e-38 so couple digits over and under(within 32bit precision). Have you actually had that kind of unit confusion in metric, or inferring from your experience with Imperial system? It kind of just seems to reinforce suggestion that Imperial system having bunch of redundant or weird units IS the problem. (for your defense: try [METRIC_UNIT]/h and /s. e.g. km/h often used for display in slow vehicles and m/s used for calculation motions of fast objects are kind of confusing.)
Steve44 4y ago
> You might have one thing measuring fuel burn rate in grams/second and another in kg/second. One of my jobs is reporting on packaging weights[1] in the UK and it's not uncommon to have this problem when I request data. For example we request in Kgs, but one manufacturer sent back the report table of numbers in grams. That meant the thin plastic sleeve a tube of paper coffee cups comes in was reported at 30Kgs rather than 30g. These components are all taxed / levied at various stages in the supply chain so being out by a factor of 1,000 can make a significant difference - we sanity check all our data, but a surprising number of people don't. It's not life threatening, but expensive! [1] It's for the UK packaging waste regulations and packaging taxes. For a case of paper coffee cups we report on the weight and materials of every component such as the cardboard outer box, labels, parcel tape, inner sleeve bags, paper in the cups and the plastic lining in the cups.

fnordpiglet 4y ago

I mean what issues would power of 10 fractions have in floating point after all?

sbradford26 4y ago
If I have data going out on a data bus in grams/second, but someone reading that data in a different sub system reads it and thinks it is kilograms/second because that is the default unit they use then you have an issue. The actual conversion of the bits isn't the issue it is that certain systems might use different units internally and making sure those conversions are done correctly. It is much more an engineering design/human interaction issue than a computation issue.
- fnordpiglet 4y ago
  Yes, I understood that. However repeated conversions can lead to rounding errors such as catastrophic cancellation. This is even more esoteric than “grams here kilograms there” and thus easier to fall prey to. Depending on how precise your measurements are you could easily drop significant digits or add random noise, especially if you do large scale changes. https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...
  - sbradford26 4y ago
    Yeah we tended to utilize fixed point for many of our variables and documented the precision for each one. Then an analysis was done verifying that we were maintaining precision through the calculations from input from a sensor to output.
    - fnordpiglet 4y ago
      The problem is almost nothing today accelerates fixed point and everything supports floating point accelerations, which will speed up your ability to calculate the wrong number by many orders of magnitude.
      - sbradford26 4y ago
        Yeah that makes sense. In aerospace they will fall on the side of accuracy even at the expense of speed. But they also tend to utilize FPGAs that can be designed to handle fixed point calculations quickly but with that comes a lot of cost and specialty hardware.
        fnordpiglet 4y ago
        Another place it makes issues is financial modeling, particularly for complex derivatives where the model might be extremely complex and small errors can accumulate into meaningful errors in risk calculations. Fixed point is sometimes used in finance but performance is also a real concern. There’s a lot you can do to reduce fp errors if your numerical libraries are carefully constructed. But it has often made me wonder why there aren’t processor lines with high performance fixed point since the math is extremely easy - even by just shifting the mantissa and working in integer space then shifting it back.
- Merad 4y ago
  Pretty sure GP was making a sarcastic comment referencing how floating point is notorious for subtle rounding issues when handling values that have an exact representation in base 10 but a repeating pattern in binary.
  - fnordpiglet 4y ago
    Yeah. Given we’ve moved from counting on our fingers to counting on our computers we need a new base 2 metric.

chriswarbo 4y ago

> You might have one thing measuring fuel burn rate in grams/second and another in kg/second This sort of redundancy is a big problem with metric (e.g. hours, litres, tonnes, etc.); and why it's better to stick to the SI subset. http://www.chriswarbo.net/projects/units/improving_our_units.html#problems-with-metric http://www.chriswarbo.net/projects/units/improving_our_units... In particular, SI is "coherent" https://en.wikipedia.org/wiki/Coherence_(units_of_measurement) https://en.wikipedia.org/wiki/Coherence_(units_of_measuremen... - There is only one unit for each dimension. In your example, "grams/second" would not be a valid unit; SI only has kilograms/second (yes, it's annoying that the unit of mass has a name beginning "kilo" :( ) - The conversion factor between different dimensions is exactly 1 (by definition). In your example, the rate R is related to mass M and time T via M = TR (i.e. kilograms = seconds × kilograms/second). There are no conversion factors, since the unit of rate is derived from the units of time and mass (unlike, say, measuring energy as calories OR pound-feet OR coulomb-volts OR ounce-miles OR slug-acres-per-squared-hour OR ...) See also http://www.chriswarbo.net/projects/units/metric_red_herring.html#metric-conversions-multiply-by-one http://www.chriswarbo.net/projects/units/metric_red_herring....

sbradford26 4y ago
When designing new systems it is best to clearly define the expected units for everything clearly at the start. SI units are great but sometimes they are not great for the specific use case. When measuring high power systems like power plants or EVs kW/MW/GW are a more appropriate unit versus Watts. In embedded systems you have limited bandwidth having to have large variables just to store values in SI units is a waste versus using an appropriately scaled unit and saving bandwidth. Overall the conversion of the unit isn't the root of the issue. Clearly defining the data types and units of everything is the key issue. This makes sure any conversion is done when necessary and allows people to design systems so that they can avoid conversion if possible.
- numpad0 4y ago
  INT_MAX is usually 2147483648, which means a "power" figure in Watt can handle anything from a laptop CPU to a Chernobyl power plant. FLT_MAX and _MIN are e+38 and e-38 so couple digits over and under(within 32bit precision). Have you actually had that kind of unit confusion in metric, or inferring from your experience with Imperial system? It kind of just seems to reinforce suggestion that Imperial system having bunch of redundant or weird units IS the problem. (for your defense: try [METRIC_UNIT]/h and /s. e.g. km/h often used for display in slow vehicles and m/s used for calculation motions of fast objects are kind of confusing.)

Steve44 4y ago

> You might have one thing measuring fuel burn rate in grams/second and another in kg/second. One of my jobs is reporting on packaging weights[1] in the UK and it's not uncommon to have this problem when I request data. For example we request in Kgs, but one manufacturer sent back the report table of numbers in grams. That meant the thin plastic sleeve a tube of paper coffee cups comes in was reported at 30Kgs rather than 30g. These components are all taxed / levied at various stages in the supply chain so being out by a factor of 1,000 can make a significant difference - we sanity check all our data, but a surprising number of people don't. It's not life threatening, but expensive! [1] It's for the UK packaging waste regulations and packaging taxes. For a case of paper coffee cups we report on the weight and materials of every component such as the cardboard outer box, labels, parcel tape, inner sleeve bags, paper in the cups and the plastic lining in the cups.