This question already has answers here:
Why does adding a small float to a large float just drop the small one?
(4 answers)
Integers and float precision
(9 answers)
epsilon for various float values
(1 answer)
Closed 5 years ago.
#include<stdio.h>
int main()
{
int loopCounter = 0;
float data1,data2;
data1 = 2000.0f;
data2 = 0.0001f;
while(1)
{
data1 = data1 + data2;
printf("Loop Counter %d , Data %f\n",loopCounter,data1);
loopCounter++;
}
return 0;
}
I am running this code on Linux machine using the GCC compiler but if the addition of the 2 float reaches the value 2048.0 it does not change anymore.
Does anyone have an idea why this is happening?
For any floating point value, in combination with a (much) smaller adding delta, there is a value from which adding the delta results in a value which is so "similar" to the previous one, that the representation in float is identical.
Your code is practically tailor-made to find that value.
So, while at first adding delta to 2000 and a few following values results in visible changes, your code will sooner or later (quite soon actually) reach the special value. Which I assume in your case is 2048.
2048.0 and 2048.0001 have no different representation in float. Hence the adding has no effect on the variable.
Anyone has idea why this is happening?
Because of floating point precision.
Read Ranges of floating point datatype in C?
Notice that:
2000.0001
already exceeds the limit a float can store (~7 digits for IEEE-754 single precision).
What happens in your case is that the precision is limited, which results in the "halting" issue you report. In other words, after some point, the adition doesn't have any actual effect (which is reflected to the user).
By that I mean that the new sum is so close to the previous sum, that their float reprecentation is the same, causing data1 to store the same value.
In your machine, this value is 2048 and all the rest additions by a small δ do not affect the float representation of data1.
Related
This question already has answers here:
c++ pow(2,1000) is normaly to big for double, but it's working. why?
(3 answers)
Closed 1 year ago.
sorry if this is a silly question, I am relatively new to C programming. Thus I have probably misunderstood something fundamental about variables/overflows.
I made this simple program and I can't explain the result
#include <stdio.h>
#include <math.h>
int main() {
double number = pow(2, 1000);
printf("%f\n", number);
}
The result of that (compiled with gcc) is a humongous number that should never fit in a variable of type double: 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376.000000
Usually when I try to assign a constant that is too large for it's type the compiler gives me an error.
So my question is: What is this number? Why am I not getting any errors? Is the variable number actually storing this value? Plainly, what's happening?
Doubles are not stored like integers. This page explains how double are representated in memory
Doubles contain 1 byte of sign, 11 bits for the exponent and 53 bits for the sigificand precision. Thus you can store numbers up to 1.7*10^308. Thus, your number cand be represented in a double (although with a limited precision). When printing it with %f, you just get its numerical value (approximated).
In C, double type can fit more than 300 decimal digits! A double is stored in 8 bytes, holding a number in the range 2.3E-308 to 1.7E+308 (15 decimal places accuracy).
Reference: https://www.tutorialspoint.com/cprogramming/c_data_types.htm
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:
Why are floating point numbers inaccurate?
(5 answers)
Closed 6 years ago.
i started learning c. Today, while i am working on a program, i found an interesting thing and i made another small program (similar to my issue) to check it.
#include<stdio.h>
int main(void)
{
float num1=867.0;
float num2=.6921;
printf("sum = %.4f \n",num1+num2);
return 0;
}
if i run the above program, i am getting 867.6921 as the answer. but if i changed the .4%f to %f the answer is changing to sum = 867.692078. why's the change in the output? Also, is there any way that i can get the answer without using the .4%f?
but if i changed the .4%f to %f the answer is changing to sum = 867.692078
printf rounds the result to that many digits after the floating point you specified, the default is .6. While rounding, it uses the current floating point rounding mode, the default is round to the nearest.
The float type has about seven digits of precision (can be anywhere from 6-9 digits). One alternative is to use g instead of f. This fixes the number of precise digits in the number, not just those after the decimal.
printf("sum = %.7g \n",num1+num2);
This produces output
sum = 867.6921
and will always give seven digits of precision for any input. Number formats would be like :
0.000000E+07
0000000
000000.0
00000.00
0000.000
000.0000
...etc
This question already has answers here:
What decides what datatype that will be used to store the temporary value in?
(3 answers)
Closed 7 years ago.
int a=10;
float b;
printf("the no\n");
b=((10-1)/12)*50;
printf("b value is %f",b);
return 0;
But when I calculate the b value in scientific calc we get b=40. And my question is why it shows b=0 when I run my code
In the calculation, the expression ((10-1)/12) is a division of an integer by an integer. The first integer evaluates to 9, and since 9/12 is less than 1, 9/12 evaluates to 0. This 0 is then multiplied by 50 to give b = 0.
To make the division act like a float, make one of the constants in the division portion a float. You can do this several ways the shortest of which is to add "f" as a suffix to one of the numbers, e.g. use 10F instead of 10, to get ((10F-1)/12). This makes the subtraction a floating point operation, which make the division and then multiplication of your original expression floating point operations as well. This should then give you the expected (float) result.
There will be a loss of data when you try to perform integer division. As already explained,
b=((10-1)/12)*50;
will yield 0 because :
((10-1)/12)*50; = (9/12)*50; = (0)*50; = 0;
To prevent this data loss, you can do the following:
((10-1)/12.0)*50;
Basically, by 12.0, it will be read as a float, so appropriately, floating point division will be performed.
This question already has answers here:
Floating point comparison [duplicate]
(5 answers)
Closed 9 years ago.
main()
{
float f=0.7;
if(0.7>f)
printf("Hi");
else
printf("Hello"):
}
When I compile this program output comes out to be Hi.
Can someone please explain the scenerio how 0.7>0.7 is true? Is this due to fact that 0.7 used in if statement is a double and f is a float?
Even if it is double still its value is 0.7 difference created is just that in case of double it is stored in 8 byte while in case of float it is stored in 4 byte. But I think it does not matters how big is your container when the value stored in container is equal. So 0.7 can never be greater than f. So according to me it should result in Hello. then why Hi is the output?
The container does makes the difference here. The idea is how these values are stored and then retrieved. If you use a number that can be converted back to exact decimal value. You may see the difference.
Use this and see the output:
float f=0.7f;
If you define float f = 0.7, it is stored as manttisa and exponent. It depends on the precision. So in this case .7 will be less than .7. If you define 0.7f it will be equal to 0.7.