24 views

Skip to first unread message

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

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.

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.

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

to mpir-devel

thanks Bill.

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

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.

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
>

> thanks Bill.

>

> I am confused. As you said, i can NOT initialize mpf_t via a double, right?

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.

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.

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？

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

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.

exactly representable in binary.

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.

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

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.

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.
>

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

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.

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 view this discussion on the web visit https://groups.google.com/d/msgid/mpir-devel/095760f7-9477-40e7-9e96-015df643e7c4o%40googlegroups.com.

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.

Aug 12, 2020, 9:58:09 PM8/12/20

to mpir-devel

Regarding floating-point surprises with 0.1...

To read more on this topic, one can read the chapter

"Floating-point numbers" in the book

- Paul Zimmermann et al.

Computational Mathematics with SageMath

Another famous source is:

- David Goldberg.

What every computer scientist should know

about floating-point arithmetic.

- 1991 original

- 2004 edited reprint

Many variations now exist:

- What every programmer should know

about floating-point arithmetic

or "Why don’t my numbers add up?"

- What every agent-based modeller should not (ideally)

have to know about floating point arithmetic

- What every javascript developer

should know about floating points

- What every programmer

should know about floating-point arithmetic

- Floating point demystified, part 1

- Floating point demystified, part 2

- What every embedded programmer should know about ...

floating point numbers

Somewhat related:

- Florian Loitsch.

Printing floating-point numbers quickly and accurately with integers

- Marc Andrysco, Ranjit Jhala, Sorin Lerner.

Printing floating-point numbers --- an always correct method.

Some videos:

- Abishalini Sivaraman.

Decimal to IEEE 754 floating point representation.

- Floating Point Numbers - Computerphile

Samuel

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu