Hacker News new | ask | show | jobs
by hinkley 3914 days ago
The speed of the answer doesn't matter so much when the answer is wrong. And (after checking Google) BOTH of those are wrong. :/
2 comments
dpayne 3914 days ago
Recompiling without fastmath gives the same answer as the article "3.1415926545880506".

  mac >> clang++ -O3 -march=native main.cpp
  mac >> ./a.out
  3.1415926545880506
  total time taken is: 4.3861569999999999s
Twice as slow as the fastmath version but still faster than the go version.
link
e12e 3914 days ago
Clearly the two results are different, so something strange is going on. But you need to define wrong, consider incrementally approximating pi in 7 steps:

  100,50,25,12,4,2,3,3.5
  > 3.5
Or even:

  100,90,80,70,60,50,40
  > 40
I'm assuming you mean wrong as in the algorithm implemented with arbitrary precision would en up with a different set of digits for the number of iterations given? Or something along those lines?
link
hinkley 3914 days ago
Oh, I mean they're both wrong in the 10th position even though they agree. But it is curious that they diverge after that.

It's probably more a problem of the algorithm not calculating significant figures and truncating the answer.

link
kmill 3914 days ago
The algorithm is computing an alternating series, with the largest n being 5x10^7. The error in an alternating series (when the sequence is strictly decreasing in absolute value) is the absolute value of the next term. This is 4/(2*(5x10^7 + 1) + 1), which is a bit less than 4x10^-8, so we would only expect 7 digits to be correct. In fact, it is the 8th digit which goes awry (not the 10th): it should be a 5 rather than a 7.

This particular series, which comes from a series for the arctan of 1, has very slow convergence. An easily better one is Machin's formula, which converges faster than a geometric series (that is, the number of terms needed is at most linear in the number of wanted digits).

link
e12e 3914 days ago
However, according to math.pi in python3.3 the second number (with higher number of iterations) is closer to pi than the lower iteration number.

So is it possible that the algorithm doesn't converge to correct digits for so "few" iterations?

link