This question already has answers here:
Comparing float and double in C
(2 answers)
strange output in comparison of float with float literal
(8 answers)
Closed 1 year ago.
Can someone pls explain me why this is not printing hello?
int main(){
float i;
i=1.2;
while (i==1.2){
printf("hello");
}
Computers only store digital information. Integers can be represented accurately in binary, but floating point numbers are approximated.
It seems that in the approximations, additional tiny values are preventing your exact comparison from being true.
Now is a good time to google "what every programmer should know about floating point numbers" and read it. It will save you countless hours of future programming and debugging if you learn it early.
In addition, there are two floating point types "float" and "double". You are comparing a float to a double, so the approximations of the value are likely not the same approximation, creating more of a chance that the two values won't be equal.
Related
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 2 years ago.
N00b here, in C I assign a value using
#include <stdio.h>
int main(){
double test_num;
test_num = 0.99999999;
printf("%11.10f\t",test_num);
printf("foo");
return 1;
}
Here's the print output
0.9999999900 foo
Here's the value from debugger (Clion 2020.1, LLDB 9.0.1, Bundled compiler)
0.99999998999999994
Why are these numbers different? The compiled/runtime value seems to be the debugger value which is breaking my program
The closest IEEE 754 64-bit binary float to 0.99999999 is 0.99999998999999994975240724670584313571453094482421875. That is the value your program is actually working with. It differs from 0.99999999 by about 5e-17. Is that difference big enough to matter in your program?
0.99999998999999994 is the result of truncating to 17 significant digits. Rounding to 10 digits would get the printf result.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
For some reason, ceil(x) rounds up round numbers to x+1.
For example:
double og_grade = 50;
double fact_grade = ceil(og_grade*1.1);
og_grade*1.1 should be 55.0000, but ceil(og_grade*1.1) returns 56.0000
Note that og_grade is always a whole number.
I tried the ceil(x) function, but for some reason when x in already
round, it rounds it up to x+1
No that would mean that the implementation of ceil was defective. Not impossible but extremely unlikely.
It's likely that the x for which this effect is observed is in fact not integral, and the decimal portion is omitted from the formatting or debugger.
Assuming IEEE754, the closest double to 1.1 is slightly larger than that; this most likely accounts for your result.
In your case, given that op_grade is in fact a whole number, your best bet is to use an int for op_grade, and multiply by 11 instead; the subsequent rounding checks are then both trivial and exact.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
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);
}
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)
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.
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.
This question already has answers here:
Is floating point math broken?
(31 answers)
Floating point inaccuracy examples
(7 answers)
Closed 6 years ago.
i would like to know what is my problem when i try to print some float values, for example, in this simple programme :
float n = 127.998 ;
printf("%f",n);
The execution gives : 127.998001.
So why i have the additional 1 back of this number ?
Some values cannot be accurately stored in a floating point data type. There is no guarantee that your float n = 127.998 will actually be stored as exactly 127.998 . For values that cannot be accurately represented in floating point types, the closest value to that is stored instead, which is what you got.
This question already has answers here:
How to represent FLOAT number in memory in C
(11 answers)
Closed 7 years ago.
I was reading the way, how integers are stored in variables in c, that the last bit is used for the sign of the integer and the remaining bits are used to store the number.
But if we take a double variable and the long int variable in c, both has a size of 4 bytes but the float can store the very huge numbers up to a range of 1038 but long int of same size cant store such huge value.
I want to understand the mechanism which is used in storage in float.
The C language does not require any specific representation for floating point numbers.
Today, most C implementations are using IEEE floating numbers (exceptions are unusual, perhaps some Series Z mainframes from IBM).
Read http://floating-point-gui.de/
The complete explanation can be found here . Basically, the number is not fully stored, only approximately. The 32 bits are used to store as much precision as possible.