strange behavior about mpf

wei zhao

unread,

Aug 10, 2020, 2:32:30 AM8/10/20

to mpir-devel

hi all,

I wrote a simple code to test mpir and found a strange thing.

the code is

mpf_t a;

mpf_init2(a, 128);

mpf_set_d(a, 0.1);

mp_exp_t exp;

char str[256];

mpf_get_str(str, &exp, 10, 128, a);

I checked str, and it was "1000000000000000055511151231257827021182" instead of "1000000000000000000000000000000000000000".

anybody knows why? Does not it affect the computation precision? how can I make the variable more accurate?

thansk a lot

wei

Bill Hart

unread,

Aug 10, 2020, 2:45:56 AM8/10/20

to mpir-devel

You are setting it to the double 0.1, which only has 53 bits
precision. You can't get more precision than you put in.

Try setting it to 0.5 first (which can be represented exactly in
binary), and then divide by the integer 5, which is also able to be
represented exactly in binary. Then you will get the 128 bits you are
after.

By the way, the mpf module isn't used much any more. You should look
into mpfr (mpfr.org) instead, which is quite often much faster, and
has more functionality and development effort.

Bill.

> --
> You received this message because you are subscribed to the Google Groups "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mpir-devel/4dca16b4-7b7d-4a16-91c6-834def1f8f97o%40googlegroups.com.

wei zhao

unread,

Aug 10, 2020, 4:08:05 AM8/10/20

to mpir-devel

thanks Bill.

I am confused. As you said, i can NOT initialize mpf_t via a double, right? The reason I turn to multiple-precision is that I hope mpir could provide more precision, double does have 53bit precision, but mpf_z should have more.

if so, mpir is not more accurate than double, because it adds some random numbers at the end, which will affect the computation result.

any idea to solve this issue？

thanks.

在 2020年8月10日星期一 UTC+8下午2:45:56，Bill Hart写道：

> To unsubscribe from this group and stop receiving emails from it, send an email to mpir-...@googlegroups.com.

Bill Hart

unread,

Aug 10, 2020, 4:23:00 AM8/10/20

to mpir-devel

On Mon, 10 Aug 2020 at 10:08, wei zhao <zwleop...@gmail.com> wrote:
>
> thanks Bill.
>
> I am confused. As you said, i can NOT initialize mpf_t via a double, right?

I did not say that. I said that doubles have 53 bits precision. You
cannot get more precision from mpf if you start with 53 bits of
precision at the input.

> The reason I turn to multiple-precision is that I hope mpir could provide more precision, double does have 53bit precision, but mpf_z should have more.

It does allow more precision, but you cannot start with less
information than you want to end up with. mpf is not able to add
precision that wasn't there to start with. The information was already
lost in the conversion of 0.1 decimal to a double (binary). This
happened before mpf even got the value.

>
> if so, mpir is not more accurate than double, because it adds some random numbers at the end, which will affect the computation result.

No it does not "add random numbers". This is what 0.1 looks like to 53
bits of precision, which is precisely what you passed into the mpf
function. It stored exactly what you gave it.

>
> any idea to solve this issue？

I already told you exactly how to solve the issue in my previous post.
Did you try it?

Decimal fractions aren't always exactly representable in (limited
precision) binary. One way to solve it would be to put in an integer,
then divide by a power of 10. Integers and powers of 10 are exactly
representable in binary.

Bill.

> To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mpir-devel/22b82e2c-cc4d-4557-9f8d-ce7c434aa5ado%40googlegroups.com.

Bill Hart

unread,

Aug 10, 2020, 4:24:43 AM8/10/20

to mpir-devel

Correction: integers and powers of 10 with non-negative exponent are
exactly representable in binary.

wei zhao

unread,

Aug 10, 2020, 4:48:08 AM8/10/20

to mpir-devel

emmmmm, i just hope mpir tries to add 0s at the end when conversion.

i tried mpf_set_str(), it seems give me correct result.

wei.

在 2020年8月10日星期一 UTC+8下午4:24:43，Bill Hart写道：

> > To view this discussion on the web visit https://groups.google.com/d/msgid/mpir-devel/22b82e2c-cc4d-4557-9f8d-ce7c434aa5ado%40googlegroups.com.

Bill Hart

unread,

Aug 10, 2020, 5:11:03 AM8/10/20

to mpir-devel

On Mon, 10 Aug 2020 at 10:48, wei zhao <zwleop...@gmail.com> wrote:
>
> emmmmm, i just hope mpir tries to add 0s at the end when conversion.

It doesn't add *anything* at the end. There is nothing after the end.
Once you reach the limit of the precision, there is no further data
after that point.

Finite precision means there's a finite number of bits. There's
nothing after those bits. Only finitely many bits are stored.

>
> i tried mpf_set_str(), it seems give me correct result.

It will give you the nearest approximation to the decimal value using
the the precision you set.

mpf is NOT a decimal system, it is a binary system. I think you are
confused about this. There is no exact conversion between fractional
decimal numbers to a given (decimal) precision and fractional binary
numbers to a given (binary) precision. The precision in mpf is a
BINARY precision, not a decimal one. You can lose information
converting between decimal and binary! That has nothing to do with
mpf. It is a feature of the mathematics itself.

The random digits you see are because you lost information converting
from decimal to binary and back again. mpf does not store the decimal
number. It stores a binary approximation. So when you convert back to
decimal, some information is gone and cannot be retrieved.

Think about it, how would YOU write 0.1 decimal in binary? It's not
possible in a finite number of bits.

Bill.

> To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mpir-devel/095760f7-9477-40e7-9e96-015df643e7c4o%40googlegroups.com.

Kevin Hake

unread,

Aug 10, 2020, 10:18:58 PM8/10/20

to mpir-devel

Hey there, what Bill explained is exactly right. And sounds like you did discover the right way to enter your 1/10th (using the string interface).

I think maybe there's still some confusion, and I think it stems from the way C (or C++, and the compilers for many languages) interprets number literals.

You wrote: mpf_set_d(a, 0.1);

The C compiler (or C++, and really the compilers for many languages) reads your "0.1" and turns it into a floating point number (most likely a double, by default, as Bill mentioned). So the number that C inputs into the function is not "one tenth", it is "whatever number represented in the n bits available in this floating point number that is closest to one part in 10". If one modified mpf_set_d to change the input ".1000000000000000055511151231257827021182" to ".1", then what should the function do when you actually want to set the input to ".1000000000000000055511151231257827021182"? Imagine pouring 2 liters of water into a 1 liter jug. When I measure the water in your jug, I will say you have exactly 1 liter. (In real life, you are pouring 1/10th into a double, and handing the double to mpir :p )

Anyway your answer, which you already have, is to not use mpf_set_d when you need to set an exact fraction that can't be exactly represented by a finite floating point number. mpf_set_str reads your text ".1" and it knows you want the exact fraction 1/10, and it creates that in the arbitrary precision variable. By using mpf_set_str your string text is interpreted by mpir and is converted without loss of precision.

The alternative, as Bill pointed out, which doesn't involve parsing an input string, is to generate the actual fraction by setting a numerator and then dividing.