Inaccurate Radians/Degrees conversion

[pieterb@…]

LS,

The conversion from angles in degrees to radians currently uses a conversion factor of 6.28318530718/360. (File: boost\units\base_units\angle\degree.hpp), which equals 0.0174532925199444444...

This is unnecessarily inaccurate (only 14 significant digits are correct) and gives problems in my application - the actual value reads: 0.017453292519943295769236907684886127134428718885417...

Using this value improves conversion accuracy significantly.

Please consider using this more accurate value. Alternatively, the use of boost::math::constants could be considered, making the factor: boost::math::constants::pi<double>()/180.0 which works fine as well.

[anonymous]

Any update on this? I see the same constant is used in boost 1.54. It would be good to not introduce unnecessary and avoidable inaccuracies in such a foundational location.

[anonymous]

There already exist the necessary constants

boost::math::constants::radian (=180/pi)

and

boost::math::constants::degree (=pi/180)

[Roger Leigh <rleigh@…>]

The constants in boost/match/constants/constants.hpp certainly appear to have the necessary accuracy. I was somewhat surprised to see only 4 d.p. accuracy when using boost::units conversions between rad/grad/deg due to the low precision constants used here while I was writing unit tests to validate the conversions. Updating it to use the math constants would be much appreciated. Do you need a patch providing?

[rleigh@…]

Use boost::math pi constant to increase precision

[Roger Leigh <rleigh@…>]

I have added a patch which makes the suggested change to use boost::math::constants::pi (actually, two_pi) to improve the precision. I've tested this locally and all my own unit tests continue to pass with the patched headers.

[Roger Leigh <rleigh@…>]

Updated patch; use degree constant directly (not possible for grad--no constant defined)

[Roger Leigh <rleigh@…>]

PR opened: ​https://github.com/boostorg/units/pull/18

[anonymous]

Please at least change the value to a more precise value if there is no agreement on the best way to retrieve the good value or if we don't want to introduce dependencies on other boost header.

Keeping a needlessly inaccurate value for 6 years is clearly the worst possible situation.