gmp_float backend with variable precision does not have distributive property

[Tobias Beck <Tobias.Beck@…>]

A simple example (attached) shows that the GMP backend (and MPFR as well) do not fulfill the distributive property when variable precision is chosen. This happens when values are initialized by fractions. It does not happen, when values are initialized by simple double values.

[Tobias Beck <Tobias.Beck@…>]

test case to reproduce the problem

[Tobias Beck <Tobias.Beck@…>]

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

[John Maddock]

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.

[Tobias Beck <Tobias.Beck@…>]

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]

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.

[Tobias Beck <Tobias.Beck@…>]

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