This question already has answers here:
What is the most effective way for float and double comparison?
(34 answers)
Closed 6 years ago.
This post stated that you shouldn't compare floating point variables with == because of rounding errors. What should I use then, and when?
You could use something along the lines of
if (abs(result - expected) < 0.00001)
or for a relative, rather than absolute, error:
float relativeError = abs((A - B) / B);
if (relativeError <= maxRelativeError)
See this for more details.
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
Related
This question already has answers here:
Dividing two integers to produce a float result [duplicate]
(1 answer)
What is the behavior of integer division?
(6 answers)
Closed 9 months ago.
I'm new at programming stuff and i'm practicing with variables, so i made a code in C++ where basically i do something like this:
float a;
a=4/3;
printf("%f", a);
return 0;
i expected to get the result as 1.333, but instead i got 1 as value
But if i do this:
float a, b=4, c=3;
a=b/c;
printf("%f", a);
return 0;
It gives back the right value (1.3333)
can somenone please explain that to me?
Ah, C++ being less than helpful. This is going to annoy you.
4 / 3
This is INTEGER math, not floating point. This would work if you did one of these:
4.0 / 3
4 / 3.0
4.0 / 3.0
C++ won't upscale your values to floating point while doing the calculation unless there are floating point values somewhere in the calculation itself.
This question already has answers here:
Is floating point math broken?
(31 answers)
exact representation of floating points in c
(9 answers)
Comparing actual float value to a float variable in C
(3 answers)
Closed 5 years ago.
I got a question to find the output of below code snippet
int main(int argc, char const *argv[])
{
float a=0.7;
if(a<0.7)
std::cout<<"yes";
else
std::cout<<"no";
}
At first look, like everyone my answer was "no" because 0.7 is not less than 0.7. But when i run it, output was "yes". I found an explanation about this which says C++ internally takes 0.7 as double value and here actually it is checking whether 0.700 < 0.7ff which will be true. So i tried the same with another value 0.5. But then this program had "no" as output. Why it is so? Doesn't it really check whether 0.500<0.5ff?, or all my understanding about it is wrong?
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 7 years ago.
I'v ran into another anomaly:
float T = 19.0 / 99.0;
float moo = (99.0 * T) - 19.0;
as expected, T = 0.191919, however 'moo' is meant to be 0 but instead is 7.450586.
I can only presume some form of casting is once again required somewhere.
Change your code to this and you will get 0 on moo
float T = 19.0f / 99.0f;
float moo = (99.0f * T) - 19.0f;
Also the value on moo without this is not 7.45, it is 7.45058e-08 which is almost zero.
Since any floating point numbers are represented in 2's complement notation in c++.you will usually get approximate values , while manipulating floating point values .So 7.450586e-008 is exact behaviour . If you need more precision use double.
This question already has answers here:
Dividing 1/n always returns 0.0 [duplicate]
(3 answers)
Closed 8 years ago.
when i try to calculate any expression, I always get an integer result, it's like:
float k= 5/12;
std::cout<< k<<std::endl;
the output in the console is always 0.
In C/C++, this is an integer division:
5/12
What you want is a floating point division:
5.0/12.0
Please note that this has absolutely nothing to do with GLUT or OpenGL.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 8 years ago.
Why when I use multiplication
float a= 1.0500000f;
float b= a*100.0f;
why b is 104.99999 but not 105.0 ?
and when I
int f= (int)b;
f is 104
Floating point numbers are not infinitely accurate -- the wikipedia page on Float numbers is quite interesting to read.
On your second question: (int)b truncates anything that occurs after the comma. This means that, in your case, 104.99999 becomes 104. So when you create a rounding error, and then cast it to an integer, you are indeed running the risk of getting a lower number.