boost.interval for tracking floating point rounding errors
Hi, I'm curious if it is possible to make boost.interval more convenient to use for tracking floating point rounding errors. Currently, you run into problems if you do naive things like boost::numeric::interval<double> x(0.1); since the 0.1 value gets rounded once by the compiler before the interval constructor ever sees it. Also, things like boost::numeric::interval<double> y(2), z; z = 0.1 * y; have similar problems. -- Frank
Le vendredi 02 septembre 2005 à 14:51 -0400, Frank Hess a écrit :
Hi,
I'm curious if it is possible to make boost.interval more convenient to use for tracking floating point rounding errors. Currently, you run into problems if you do naive things like
boost::numeric::interval<double> x(0.1);
since the 0.1 value gets rounded once by the compiler before the interval constructor ever sees it. Also, things like
boost::numeric::interval<double> y(2), z; z = 0.1 * y;
have similar problems.
Unfortunately, as soon as you write 0.1, you lose: the compiler will round it to a floating-point number close to 0.1 (it is not even guaranteed to be the closest one) and you have no way to know it was 0.1 initially. Some other interval libraries allow for interval(char const *) constructors. It then allows you to write complex expressions. For this particular example, the expression is quite simple: interval x("0.1"); There is no such thing in the Boost library. But here are a few solutions though: namespace bni = boost::numeric::interval_lib; typedef boost::numeric::interval<double> I; I x1 = bni::widen(I(0.1), std::numeric_limits<double>::min()); // or denorm_min() I x2 = bni::div<I>(1, 10); Both intervals will contain the exact real value 0.1. The second one is the tightest interval (the first one is 2 ulps wide). Unfortunately, even these solutions may not work if the compiler decides to optimize the code by computing the intervals at compile-time. You will have to test that the interval x is not singleton. If it is, you will have to start playing trick with volatile variables, FENV_ACCESS pragmas, or command-line compiler options. Best regards, Guillaume
participants (2)
-
Frank Hess
-
Guillaume Melquiond