0

The German mathematician Gottfried Leibniz developed the following method to approximate the value of π:

π/4 = 1 - 1/3 + 1/5 - 1/7 + . . .

Write a program that allows the user to specify the number of iterations used in this approximation and that displays the resulting value.

An example of the program input and output is shown below:

Enter the number of iterations: 5 The approximation of pi is
3.3396825396825403

I've gotten the first two checks correct but as soon as I enter double digits it begins to get the wrong numbers at the very end of the chain. Could anyone help me?

number=float(input("Enter the number iterations: "))
pi=0
div=1

while(div<=number):
    positive_value = 4/(2*div-1) 
    pi += positive_value
    div=div+2

div=2

while(div<=number):
    negative_value=4/(2*div-1)
    pi -=negative_value
    div=div+2

print("The approximation of pi is %.16f "%pi)
John Kugelman
  • 349,597
  • 67
  • 533
  • 578
Jaylee
  • 11
  • 1
  • 3
    Does this answer your question? [Is floating point math broken?](https://stackoverflow.com/questions/588004/is-floating-point-math-broken) – Random Davis Oct 14 '20 at 15:05
  • 1
    Show specific cases in which you think there are problems, and say which specific digits you think are wrong and what they should be. Even after 50,000 terms, the approximation is only good to about four digits after the decimal point, so why would you expect any digits after that to have particular values? – Eric Postpischil Oct 14 '20 at 15:10
  • Welcome to Stack Overflow! Please take the [tour] and read [ask]. You need to include details about the debugging you have tried in your code. The more relevant details you include, the easier it is for people to help. At the very least, you should include the output you see from your program so that people aren't forced to run it to see what it does wrong. – Pranav Hosangadi Oct 14 '20 at 15:12
  • You can only expect 15 to 17 digits of precision from double-precision floating point in any case. Given the number of terms, rounding errors are likely to accumulate, decreasing your effective precision. If you need a lot of digits, use an arbitrary precision math library instead of floating point. – Robert Harvey Oct 14 '20 at 15:20
  • 2
    @RolvApneseth: π is not likely any more favorable to decimal arithmetic than to binary arithmetic, and certainly the fractions involved here (1/7, 1/9, 1/11,…) are not, so why do you think using decimal would help in this situation? – Eric Postpischil Oct 14 '20 at 15:26
  • Are you comparing your output against what someone else has given you as the "correct" values? If so, can we see them, along with the matching values you're getting? – CryptoFool Oct 14 '20 at 15:56
  • There's seems to be nothing wrong with this code. You don't get into the 3.13-3.15 range until `number` is around 75. Can you [edit] your question to include what you expected to get? – Pranav Hosangadi Oct 14 '20 at 16:21

1 Answers1

0

Had the urge to write this more concise:

n = 100000

pi = 0
for i in range(1, 2*n, 2):
    pi += -4/i if (i + 1) % 4 == 0 else +4/i

And to showcase the things mentioned in the comments I reversed the order in which I add / subtract the terms, which should not make a difference if you would have infinite precision.

pi_r = 0
for i in reversed(range(1, 2*n, 2)):
    pi_r += -4/i if (i + 1) % 4 == 0 else +4/i
    
# pi   3.1415826535897198
# pi_r 3.1415826535897935
#           ^         ^
#   ==real pi         region of incorrect floating point math

So as Eric Postpischil pointed out and this test with n = 100000 shows if you are interested in the approximation to pi you should be fine as you need a lot of terms to come close to pi, therefore numerical rounding errors should not be an issue here. If on the other hand you are really interested in every single digit of the approximation you could use other tools like for example decimal or mpmath.

scleronomic
  • 4,392
  • 1
  • 13
  • 43