Boost C++ Libraries: Ticket #11102: gmp_float backend with variable precision does not have distributive property

attachment set

Wed, 11 Mar 2015 13:03:32 GMT

attachment → test.cpp

test case to reproduce the problem

Wed, 11 Mar 2015 13:07:44 GMT

Sorry, I produced a duplicate 11103, because the web page was not very responsive.

status changed; resolution set

John Maddock — Wed, 11 Mar 2015 19:16:23 GMT

status new → closed
resolution → invalid

Why would you expect this to work? Due to the way floating point values work there will always be roundoff error and I would not in general expect those two expressions to be exactly equal - even for type double. In point of fact, at least on my system they are equal when using the MPFR or cpp_bin_float backends (both of which are exactly rounded), but not for the GMP backend which does not round operations at all. Even so, I bet there are certain input values that will fail for MPFR and cpp_bin_float as well. The reason it works for you when initializing from a double is that you are only seeding a few of the bits in the mantissa with random values, and therefore there is never any rounding in any of thre operations. Seed of all of the bits in the mantissa with random values and any floating point type will fail this test.

Please reopen if I've misunderstood your point.

Thu, 12 Mar 2015 07:04:05 GMT

Maybe this is due to a misunderstanding on what "variable precision" means? I assumed, that variable precision means that the number of bits is extended to fit any result as long as we only apply multiplications, subtractions and additions. In this case the distributive law should hold independently of the initialization method.

In fact, I even assumed that internally a fractional representation is chosen to cope with the case of divisions. std::numeric_limits shows an epsilon of 0.0. I interpreted this as "values are represented exactly" (ok, at least w.r.t. certain simple operations).

In any case, maybe the term "variable precision" needs some clarification... What can we expect of a variable precision variable? Is there only a very intransparent internal way of choosing the bitness? In this case, the type is probably useless, isn't it?

John Maddock — Thu, 12 Mar 2015 10:02:10 GMT

Variable precision means you get to choose at runtime what the precision is by calling number<>::set_precision or number<>::set_default_precision. It's the same behaviour that the underlying GMP or MPFR libraries have.

Thu, 12 Mar 2015 11:01:57 GMT

Sorry, I missed that point. Thank you for the explanation.