Slug definition appears to be off by a few parts per billion #289
Comments
|
Here's me showing the steps to make it easy for others to reproduce. I'm using only integers, and I believe they all trace back to exact definitions. The end result matches the definition in the library exactly before truncation, which adds to my confidence that I performed the computation correctly. The red-underlined digits are the ones omitted by the library. |
|
Mr. Hogg, Thank you for the issue. I think you're right and your analysis is correct. The aim of |
This creates a file, `"compatibility/nholthaus_units.hh"`, which makes it easy to set up a correspondence between each Au Quantity type, and the corresponding nholthaus units type. This "correspondence" includes bidirectional implicit conversions: so, you can pass `::au::QuantityD<Meters>` to an API expecting `::units::length::meter_t`, and vice versa. This correspondence is purely opt-in. The file also needs to be included _after_ both of the other two libraries are included. Since this is fragile in general, we give instructions and an example for how to make it _not_ fragile, in `nholthaus_units_example_usage.hh`. We include a variety of unit tests to show that the quantities are indeed equivalent between the libraries. (Actually, this isn't quite always the case. These tests uncovered a bug in the nholthaus library, nholthaus/units#289.) We reserve the documentation of the corresponding-quantity feature in general, as well as its application to the nholthaus library, for a future PR.
This creates a file, `"compatibility/nholthaus_units.hh"`, which makes it easy to set up a correspondence between each Au Quantity type, and the corresponding nholthaus units type. This "correspondence" includes bidirectional implicit conversions: so, you can pass `::au::QuantityD<Meters>` to an API expecting `::units::length::meter_t`, and vice versa. This correspondence is purely opt-in. The file also needs to be included _after_ both of the other two libraries are included. Since this is fragile in general, we give instructions and an example for how to make it _not_ fragile, in `nholthaus_units_example_usage.hh`. We include a variety of unit tests to show that the quantities are indeed equivalent between the libraries. (Actually, this isn't quite always the case. These tests uncovered a bug in the nholthaus library, nholthaus/units#289.) We reserve the documentation of the corresponding-quantity feature in general, as well as its application to the nholthaus library, for a future PR. Test plan --------- - [x] Add new unit tests for this file. - [x] Add example file that shows how to use it. - [x] Test that the file can replace Aurora's existing implementation.
Please include the following information in your issue:
Which version of
unitsyou are using: 2.3.1, although this problem exists on all versions, including 3.x.Which compiler exhibited the problem (including compiler version): All of them: it's a wrong definition in the code.
A slug is defined as the mass accelerated by 1 ft/s^2 by a net force of one lbf. This works out to some exact number of kilograms, which we can find using the following other exact definitions:
When I simplify this, I get that a slug is exactly (8896443230521 / 609600000000) kg, which works out to 14.5939029372063648293963... (etc.).
However, the units library slug is defined as exactly 14.5939029 kg. This amounts to an error of a few parts per billion. The error propagates to related units, e.g., foot-pounds of torque.
I think you could fix this: the numerator and denominator both fit into a
std::intmax_tforstd::ratio. However, since you're usingstd::ratioto represent unit magnitudes, instead of a vector space representation, you'll probably be more vulnerable to overflow when defining related units.The text was updated successfully, but these errors were encountered: