How does Boost.Units come up with this imprecise result of conversion?

Question

Consider the following code:

#include <boost/units/io.hpp>
#include <boost/units/systems/si/plane_angle.hpp>
#include <boost/units/systems/angle/degrees.hpp>
#include <iostream>
#include <cmath>
#include <limits>

int main()
{
    using namespace boost::units;
    std::cout.precision(std::numeric_limits<double>::digits10);
    std::cout << "Everyone knows that 180 deg = " << std::acos(-1.) << " rad\n";
    std::cout << "Boost thinks that   180 deg = "
              << quantity<si::plane_angle,double>(180.*degree::degree) << "\n";
}

I get the following output:

Everyone knows that 180 deg = 3.14159265358979 rad
Boost thinks that   180 deg = 3.14159265359 rad

Apparently, Boost.Units gets very low precision M_PI defined somewhere manually, because it's just truncated after 12th decimal place. But as I grepped my /usr/include/, I only found this imprecise definition in /usr/include/python2.7/Imaging.h, which looks quite unrelated. All others have more decimal figures specified.

So, my question is: how does Boost come up with this result?

Purveyor

Answer 1

From boost/units/base_units/angle/degree.hpp:

BOOST_UNITS_DEFINE_BASE_UNIT_WITH_CONVERSIONS(angle,degree,"degree","deg",6.28318530718/360.,boost::units::angle::radian_base_unit,-101);

Dividing 6.28318530718 by 2 returns the value you are seeing. This certainly doesn't seem quite right, but alas, this seems to be the case.

Update: I found a bug report for this problem: https://svn.boost.org/trac/boost/ticket/6893

Consuelaconsuelo

Ah, didn't try to look for multiples of this. – Purveyor

Coincidentally, I just attached a patch to this ticket since I ran into this last week as well. You might find the patch useful as a workaround until it's fixed by a new boost release. – Obeded