Try to construct two different programs to calculate the value of
\[\sum_{k=1}^\infty \frac{1}{k^2}\]
Some will immediately noticed that this is actually \(\frac{\pi^2}{6}\), but we try doing it by definition.
First, we calculate the sum by usual order
\[1+\frac{1}{4}+\dots+\frac{1}{(N1)^2}+\frac{1}{N^2}\]
Next, we calculate the sum by reversed order
\[\frac{1}{N^2}+\frac{1}{(N1)^2}+\dots+\frac{1}{4}+1\]
The answer should be the same, even for computers, right? However, when I tried in C++
First approach:
1 2 3 4 5 6 7 

Second approach:
1 2 3 4 5 6 7 

And a constant value for reference:
1 

Three values are:
1 2 3 

So, the second approach seems more accurate, why is that?
The discrepancy is due to roundoff issues. A float holds only so many digits and (on my computer) the epsilon value for a float is around \(10^{7}\). This means that by the time the sum reaches \(k = 106\), the value held in ans is too large for the addition of \(10^{−12}\) to have any effect. Many terms at the end of the series have little or no effect on the sum; their contribution is lost. However, those tail terms do have a cumulative contribution on the actual sum and are needed to give an accurate result. By summing in the reverse order these small terms do not have their contributions lost.
C++ For Mathematicians by Edward Scheinerman
Comments
Sort by:
Top NewestAt first I thought this was something like @Mursalin Habib 's fallacies. After I finished reading it I realized it was a computer science problem :D – Tan Li Xuan · 2 years ago
Log in to reply
Try doing the same using a double instead of a float, does it return a similar result? – Petru Lupsac · 2 years ago
Log in to reply
This is just a sum of Fourier Series found in engineering mathematics for its exact proof. Sum to computing's significant figures always incur serious errors for series of less convergence which must go for a long run of up to 10^12 terms. Product to computing is relatively much more favorable with less inaccuracies. Turbo Pascal's EXTENDED of 18 S.F. appears to user is quite good to replace REAL by {$N+} or adjust numeric processing from software to 8087/80287 at Compiler under Options. – Lu Chee Ket · 1 year ago
Log in to reply
the problem is the method of storing number (float & double ) specially float. – Haroon Ahmed · 1 year, 10 months ago
Log in to reply
"zeta"? Uhm. Where is the zeta? – Magnetic Duck · 2 years ago
Log in to reply
– Christopher Boo · 2 years ago
constant is the zetaLog in to reply
Java has BigDecimal. I got
1.6449330668487264363057484999793918558856165440796 1.6449330668487264363057484999793918558856165440640 1.6449340668482264
Using MathContext mc = new MathContext(50, RoundingMode.HALF_UP); n=1000000
Executes in a couple of minutes.
My 2 numbers deviate around the 48th decimal place.
But my constant, deviates around the 6th decimal place.
If anyone wants to see the entire source code, let me know. – Frank Rodriguez · 2 years ago
Log in to reply
– Lu Chee Ket · 1 year ago
Do you have small file to send an accessible Java BigDecimal program via the internet? Where can I obtain instead?Log in to reply
When written in Visual Basic, I did not face this problem at all. – Hosam Hajjir · 2 years ago
Log in to reply
– Calvin Lin Staff · 2 years ago
Can you explain why Visual Basic worked better than C++?Log in to reply
– Hosam Hajjir · 2 years ago
Possibly because I used double precision variables (8 bytes) not float which is single precision (4 bytes) so the machine epsilon in my case is much smaller.Log in to reply
programming – Alleria Windrunner Gomez · 2 years ago
Log in to reply