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

  • Context: MHB 
  • Thread starter Thread starter mathmari
  • Start date Start date
  • Tags Tags
    Sum
Click For Summary

Discussion Overview

The discussion revolves around calculating a specific mathematical sum in C programming, focusing on the issues of floating-point precision and the differences between using float and double data types. Participants explore the implications of these choices on the accuracy of their results, particularly when summing terms of the form 1/(i(i+1)) for large values of n.

Discussion Character

  • Technical explanation
  • Mathematical reasoning
  • Debate/contested

Main Points Raised

  • Some participants note that using float leads to significant rounding errors due to its limited precision of about 7 significant digits.
  • Others suggest using double instead, which has about 16 significant digits, to improve accuracy.
  • A participant identifies an error in their code related to integer overflow when calculating i(i+1) and suggests that the multiplication should be done in floating-point types.
  • There is a discussion about the differences in results when calculating the sum forwards versus backwards, with some participants noting that the backward method seems to yield better approximations under certain conditions.
  • Participants express confusion about the behavior of floating-point arithmetic, particularly regarding how small values can be lost in repeated additions.
  • Some participants inquire about the implications of using different precision formats and how to properly declare variables to avoid overflow issues.
  • There is a mention of forward and backward error analysis, with one participant observing that the forward method performs better for smaller n, while the backward method is better for larger n.

Areas of Agreement / Disagreement

Participants generally agree that using double is preferable for accuracy, but there is disagreement regarding the performance of forward versus backward summation methods, with some asserting that the backward method should always be better, while others present conflicting results.

Contextual Notes

Participants discuss the limitations of float and double types, including potential overflow issues with integer calculations and the impact of rounding errors on results. The discussion highlights the complexity of floating-point arithmetic and the conditions under which different methods yield varying levels of accuracy.

Who May Find This Useful

This discussion may be useful for programmers and students interested in numerical methods, floating-point arithmetic, and error analysis in computational mathematics.

  • #31
I found the abolute value of (pi^2)/6-the result(for forward method:1.6439348459243774,for backward method:1.6439344882965088).
 
Physics 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 4 ·
Replies
4
Views
2K
  • · Replies 3 ·
Replies
3
Views
3K
  • · Replies 5 ·
Replies
5
Views
3K
Replies
7
Views
3K
  • · Replies 25 ·
Replies
25
Views
4K
  • · Replies 1 ·
Replies
1
Views
1K
  • · Replies 31 ·
2
Replies
31
Views
3K
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 1 ·
Replies
1
Views
3K
Replies
4
Views
2K