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