MHB Calculating a Sum in C: Finding the Error in Floating Point Precision?

  • Thread starter Thread starter mathmari
  • Start date Start date
  • Tags Tags
    Sum
Click For Summary
The discussion centers on calculating the sum of a series in C, revealing issues with floating-point precision. The user initially encounters discrepancies between calculated and expected results due to using "float" variables, which have limited precision, leading to rounding errors. Switching to "double" improves accuracy, but overflow issues arise when multiplying large integers. The conversation also touches on the benefits of calculating sums in reverse to minimize error accumulation. Ultimately, the importance of using appropriate data types and understanding floating-point behavior is emphasized for accurate computations.
  • #31
I found the abolute value of (pi^2)/6-the result(for forward method:1.6439348459243774,for backward method:1.6439344882965088).
 
Mathematics news on Phys.org
  • #32
mathmari said:
I found the abolute value of (pi^2)/6-the result(for forward method:1.6439348459243774,for backward method:1.6439344882965088).

Right.
So apparently the forward method gives a result that is higher in this case than the backward result.
However, the true result that we should have for n=1000 is best approximated by the double backward algorithm, which you already gave.

Code:
float forward   = 1.6439348459243774
float backward  = 1.6439344882965088
double backward = 1.6439345666815597

As you can see the "float backward" result is closer to the double result than the "float forward" result.
However, we do see that the "float forward" result is higher than the "float backward" result.
This would happen due to rounding errors that work out differently.
 
  • #33
So,isn't the error of the backward method bigger for n<=1000??
 
  • #34
mathmari said:
So,isn't the error of the backward method bigger for n<=1000??

The difference with $\frac{\pi^2}6$ of the backward method is bigger in this case (presumably due to "bad" rounding in the forward method that turns out to be "lucky").

However, the error in the backward result is smaller, since the result is not supposed to be $\frac{\pi^2}6$. It needs many more iterations before it gets there.
 
  • #35
If you multiply your result with 6 and find the square root and then the error,how could we explain why the forward method gives better results for smaller n?? :o:confused:
 
  • #36
mathmari said:
If you multiply your result with 6 and find the square root and then the error,how could we explain why the forward method gives better results for smaller n??

Lucky bad rounding.

Suppose we do the calculation with 2 significant decimal digits for n=4.
Then we get:
forward: ((1+0.25)+0.11)+0.063 = 1.5
backward: 1+(0.25+(0.11+0.063)) = 1.4

As you can see, the forward result is closer to $\pi^2/6 \approx 1.64$.
That is because of the lucky bad rounding of 0.25 to 0.3 and of 0.063 to 0.1.

Note that after iteration n=4, the forward result does not increase anymore (the next term is 0.04). But the backward result keeps getting closer to the desired end result.
 
  • #37
Thank you very very much! ;) :D
 

Similar threads

  • · Replies 31 ·
2
Replies
31
Views
2K
  • · Replies 7 ·
Replies
7
Views
3K
  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 22 ·
Replies
22
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 20 ·
Replies
20
Views
2K
  • · Replies 6 ·
Replies
6
Views
2K
  • · Replies 9 ·
Replies
9
Views
3K
Replies
7
Views
3K
  • · Replies 2 ·
Replies
2
Views
3K