-1

When given the input 150, I expect the output to be the mathematically correct answer 70685.7750, but I am getting the wrong output 70685.7812.

#include<stdio.h>

int main()
{
  float A,n,R;

  n=3.14159;

  scanf("%f",&R);
  A=n*(R*R);

  printf("A=%.4f\n",A);
}
caf
  • 233,326
  • 40
  • 323
  • 462
Samin Yasar
  • 17
  • 1
  • 1
    Give it another input? – Antti Haapala -- Слава Україні Sep 06 '19 at 05:36
  • Or try using `double`s instead of `float`s, at least the precision is more than 7 digits – Antti Haapala -- Слава Україні Sep 06 '19 at 05:39
  • Why are you expecting that specific output? What is the input for which you expect that? (Consider repeating the desired output in the body to make understanding the question easier.) Joke answer to clarify what I mean: `printf("A=70685.7750\n");` – Yunnosch Sep 06 '19 at 05:49
  • 1
    The number 3.14159 cannot be stored exactly in an IEE-754 32 bit float - the closest value is approximately 3.14159012. 150*150*3.14159012 is 70685.7777, and the closest value to *this* that can be represented is 70685.78125, which you are then printing with `%.4f` so you see 70685.7812. – caf Sep 06 '19 at 06:22
  • @Yunnosch: It seems to me that the only thing really missing from the question was the input number, which was probably an oversight. Sometimes I think a demonstration of how a question could have been improved is in order. – caf Sep 06 '19 at 06:41
  • @caf That is a valid point. But in this case it probably got me annoyed that the oversight was the essential part of the question combined with (by now) an hour of non-answer (yes I know that I should allow for people to ask a question and then go to bed... but that is hard, too) and the final straw of not having taken the tour. – Yunnosch Sep 06 '19 at 06:45
  • Ah well. I like people who talk things. Have my reopen vote. – Yunnosch Sep 06 '19 at 06:46
  • @caf But now do me a favor an make an answer, so that I did not reopen this only to have it rot in the list of unanswered questions. Deal? – Yunnosch Sep 06 '19 at 06:47
  • I recommend changing the title to make this now interesting question to also be "findable". Feel free to use the hindsight knowledge of the answers. – Yunnosch Sep 06 '19 at 07:05

3 Answers3

4

float and double numbers are not represented very accurately in the memory. The main reason is that the memory is limited, and most non-integers are not.

The best example is PI. You can specify as many digits as you want, but it will still be an approximation.

The limited precision of representing the numbers is the reason of the following rule:

when working with floats and double numbers, not not check for equality (m == n), but check that the difference between them is smaller than a certain error ((m-n) < e)

Please note, as mentioned in the comments too, that the above rule is not "the mother rule of all rules". There are other rules also.

Careful analysis must be done for each particular situation, in order to have a properly working application.

(Thanks @EricPostpischil for the reminder)

virolino
  • 2,073
  • 5
  • 21
  • “Compare with a tolerance” is bad general advice because, although it may reduce false negatives, it increases false positives. Without knowing the purpose of the comparison, this can break an application. For more, see [this](https://stackoverflow.com/questions/5595425/what-is-the-best-way-to-compare-floats-for-almost-equality-in-python/5629905#5629905), [this](https://stackoverflow.com/questions/47969385/go-float-comparison/47970236#47970236), and [this](https://stackoverflow.com/questions/56039679/compare-two-float-variables-in-c/56040270#56040270). – Eric Postpischil Sep 06 '19 at 11:57
  • I agree that there is no clear solution. Some false results may happen, and the algorithm must be chosen according to the analysis of each particular situation. – virolino Sep 06 '19 at 12:10
2

It is common for a variable of type float to be an IEEE-754 32-bit floating point number.

The number 3.14159 cannot be stored exactly in an IEEE-754 32-bit float - the closest value is approximately 3.14159012. 150 * 150 * 3.14159012 is 70685.7777, and the closest value to this that can be represented in a 32-bit float is 70685.78125, which you are then printing with %.4f so you see 70685.7812.

Another way of thinking about this is that your n value only ends up being accurate to the sixth significant figure, so - as you are just calculating a series of multiplications - your result is also only acccurate to the sixth significant figure (ie 70685.8). (In the general case this can be worse - for example subtraction of two close values can lead to a large increase in the relative error).

If you switch to using variables of type double (and change the scanf() to use %lf), then you will likely get the answer you are after. double is typically a 64-bit float, which means that the error in the representation of your n values and the result is small enough not to affect the fourth decimal place.

caf
  • 233,326
  • 40
  • 323
  • 462
  • It is not good to teach that a numerical format which represents six significant decimal digits generally produces results accurate to six significant figures. In anything but the simplest computations, numerical errors compound in complicated and hard-to-predict ways (there is an [entire field of study](https://en.wikipedia.org/wiki/Numerical_analysis) for them), and the final error can range from zero to infinity or even fail to produce numerical results at all. – Eric Postpischil Sep 06 '19 at 12:00
  • @EricPostpischil: I did not intend to imply anything about the general case, I have updated the answer to make this clear. – caf Sep 06 '19 at 13:31
0

Have you heard that float and double values aren't always perfectly accurate, have limited precision? Have you heard that type float gives you the equivalent of only about 7 decimal digits' worth of precision? This is what that means. Your expected and actual answers, 70685.7750 and 70685.7812, differ in the seventh digit, just about as expected.

I expect the output to be the mathematically correct answer

I am sorry to disappoint you, but that's your mistake. As a general rule, when you're doing floating-point arithmetic, you will never get the mathematically correct answer, you will always get a limited-precision approximation of the mathematically correct answer.

The canonical SO answers to this sort of question are collected at Is floating point math broken?. You might want to read some of those answers for more enlightenment.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103