Waste less time on Facebook — follow Brilliant.
×

\(a+b=b+a\)? Not quite.

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}{(N-1)^2}+\frac{1}{N^2}\]

Next, we calculate the sum by reversed order

\[\frac{1}{N^2}+\frac{1}{(N-1)^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
float zeta_up(long n){
    float ans = 0.;
    for (long k=1; k<=n; k++){
        ans += 1./float(k)/float(k);
    }
    return ans;
}

Second approach:

1
2
3
4
5
6
7
float zeta_down(long n){
    float ans = 0.;
    for (long k=n; k>=1; k--){
        ans += 1./float(k)/float(k);
    }
    return ans;
}

And a constant value for reference:

1
const float zeta = M_PI*M_PI/6.;

Three values are:

1
2
3
zeta_up   = 1.64473
zeta_down = 1.64493
constant  = 1.64493

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

Note by Christopher Boo
2 years, 7 months ago

No vote yet
1 vote

Comments

Sort by:

Top Newest

At 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, 7 months 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, 7 months 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, 7 months ago

Log in to reply

the problem is the method of storing number (float & double ) specially float. Haroon Ahmed · 2 years, 5 months ago

Log in to reply

"zeta"? Uhm. Where is the zeta? Magnetic Duck · 2 years, 7 months ago

Log in to reply

@Magnetic Duck constant is the zeta Christopher Boo · 2 years, 7 months ago

Log 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, 7 months ago

Log in to reply

@Frank Rodriguez Do you have small file to send an accessible Java BigDecimal program via the internet? Where can I obtain instead? Lu Chee Ket · 1 year, 7 months ago

Log in to reply

When written in Visual Basic, I did not face this problem at all. Hosam Hajjir · 2 years, 7 months ago

Log in to reply

@Hosam Hajjir Can you explain why Visual Basic worked better than C++? Calvin Lin Staff · 2 years, 7 months ago

Log in to reply

@Calvin Lin 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. Hosam Hajjir · 2 years, 7 months ago

Log in to reply

programming Alleria Windrunner Gomez · 2 years, 6 months ago

Log in to reply

×

Problem Loading...

Note Loading...

Set Loading...