Earlier quoted context omitted.
> 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 ea…
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 was…
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".