[sbradford26]

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.

[chriswarbo]

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

In particular, SI is "coherent" 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....

[sbradford26]

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.

[chriswarbo]

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

Those are all SI units. In fact, they're all the same unit: the Watt (almost http://www.chriswarbo.net/projects/units/metric_red_herring.... )

A non-SI example would be e.g. kilowatthours (kWH); since 'hour' is not an SI unit. The SI equivalent would be 3.6 MegaJoules.

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

This seems like a non-issue to me:

- Integer arithmetic can be "appropriately scaled"; we call it https://en.wikipedia.org/wiki/Fixed-point_arithmetic

- Floats are designed to be scaled, by adjusting their exponents. In the happy case, our algorithms don't care; so why not stick with standard units? In the unhappy case (imprecision, numeric instability) we may need a mixture of entirely bespoke representations, even within a single algorithm. Ideally we'd still use standard units at the "boundaries".

[numpad0]

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

[sbradford26]

INT_MAX is assuming every variable is using a 32 bit integer which is not always the case. In my experience with flight control systems controls systems were focused on using the smallest variable necessary for a given variable. We had many variables that were only 8 or 16 bits. The processing overhead wasn't really the driving factor for smaller variables it was typically interface bandwidth which can be very limited while maintaining required safety margins on aircraft.

We had a pretty massive ICD that defined every message going in between sub systems down to the bit level which is what was necessary to avoid unit confusion when dealing with system creates by sub contractors and such. Your example of velocity is pretty common thing that you would have to reference the ICD for. Is this velocity signal in KM/h or m/s, as well as MPH, fps, and Mach number.

Sure you could say all velocities need to be in m/s, but then if all your control laws for higher speeds which have been fined tuned through 10s of years of work utilize Mach Number in the calculations is it safer to update all the controls laws or just do a conversion?

[chriswarbo]

> Sure you could say all velocities need to be in m/s, but if all your control laws for higher speeds which have been fined tuned through 10s of years of work utilize Mach Number in the calculations is it safer to update all the controls laws or just do a conversion?

Mach Number is a dimensionless ratio; I don't understand what that could have to do with velocity units? (Any units used in its calculation have cancelled-out by that point)

[numpad0]

So 32767 m/s is like not much short of twice the Solar system escape velocity…

[Steve44]

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

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

[sbradford26]

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.

[Merad]

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]

Yeah. Given we’ve moved from counting on our fingers to counting on our computers we need a new base 2 metric.

[fnordpiglet]

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

[sbradford26]

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]

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]

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.