Help with precision using astro_float::BigFloat

help
1

EDIT: Note that there was a bug in the numerator, once the numerator is fixed, the code prints out the correct number as per Wolfram Alpha. Thanks to stencillogic!

rust-script --dep astro-float -e '
    use astro_float::{BigFloat, RoundingMode};
    let p = 1024 + 8;
    let mut pi = BigFloat::from_word(2646693125139309345, p).div(
        &BigFloat::from_word(842468587426513207, p),
        p,
        RoundingMode::None,
    );
    pi.set_precision(1024, RoundingMode::ToEven)
        .expect("Precision updated");
    println!("{}", pi);
'

Hi, I have an issue involving usage of BigFloat - let me know if I should post on that GitHub repo instead! I'm also using https://rust-script.org/ for this demo.

I'm trying to get an approximation of pi to the accuracy of 37-38 decimal places. Wolfram Alpha shows:

2646693125139304345 / 842468587426513207 = 3.141592653589793238462643383279502884183... (last digit 3 is the 39th decimal place)

Actual pi = 3.141592653589793238462643383279502884197... (note that 38th and 39th decimal places differ, 83 vs 97)

Basically, I'm trying to use BigFloat to output the correct value of the division (the number ending in 83).

However, running my code above on my machine shows:

3.1415926535897991... (15th and 16th decimal place show digits 91 which are already wrong)

May I know how to fix the precision? The docs on BigFloat seem like the library is able to deal with high precision numbers.

2

Another representation of this is:

(5 * 13 * 1106671 * 36793550903) / 842468587426513207

Or use this Wolfram Alpha link leveraging continued fractions:

Fun fact: 37 decimal places is enough for the entire universe! See this NASA link.

3

I doubt that

2646693125139304345 / 842468587426513207 = 3.141592653589793238462643383279502884183...

You have a rational number on the left and much longer irrational Pi on the right. The rational number does not contain in itself that much information about significant digits of Pi.
But if you still think there is a bug, the right thing to do is to open an issue.

4

I'm on a mobile and can't check, but as the original poster noted (and verified with Wolfram Alpha) the fraction in question is one of the convergents of pi in its continued fraction expansion and so it's an exceptionally good approximation; the error is bounded by roughly 1/q^2 where q is the denominator. For instance, 355/113 is an earlier convergent of pi and the error is 3e-7.

1 Like
5

Indeed, thanks for pointing out. In the code above there is 264669312513930**9**345, and the in the example later there is 264669312513930**4**345. That caused my confusion.

1 Like
6

Oh you're right! There's an error in the initial entry of the numerator as you pointed out.

The code now prints the same number as per Wolfram Alpha, accurate to 37 decimal places.

7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.