# Tutorial :When comparing for equality is it okay to use `==`?

### Question:

When comparing for equality is it okay to use `==`?

For example:

``int a = 3;  int b = 4;  ``

If checking for equality should you use:

``if (a == b)  {       . . .  }  ``

Would the situation change if floating point numbers were used?

### Solution:1

'`==`' is perfectly good for integer values.

You should not compare floats for equality; use an tolerance approach:

``if (fabs(a - b) < tolerance)  {     // a and b are equal to within tolerance  }  ``

### Solution:2

Re floating points: yes. Don't use == for floats (or know EXACTLY what you're doing if you do). Rather use something like

``if (fabs(a - b) < SOME_DELTA) {    ...  }  ``

EDIT: changed abs() to fabs()

### Solution:3

Doing < and > comparisons doesn't really help you with rounding errors. Use the solution given by Mark Shearar. Direct equality comparisons for floats are not always bad, though. You can use them if some specific value (e.g. 0.0 or 1.0) is directly assigned to a variable, to check if the variable still has that value. It is only after calculations where the rounding errors screw up equality checks.

Notice that comparing a NaN value to anything (also another NaN) with <, >, <=, >= or == returns false. != returns true.

### Solution:4

In many classes, `operator==` is typically implemented as `(!(a < b || b < a))`, so you should go ahead and use ==. Except for floats, as Mitch Wheat said above.

### Solution:5

While comparing ints, use ==. Using "<" and ">" at the same time to check equality on a int results in slower code because it takes two comparisons instead of one, taking the double amount of time. (altough probably the compiler will fix it for you, but you should not get used to writing bad code).

Remember, early optimization is bad, but early inefficient code is just as bad.

EDIT: Fixed some english...

### Solution:6

For integers, `==` does just what you expect. If they're equal, they're equal.

For floats, it's another story. Operations produce imprecise results and errors accumulate. You need to be a little fuzzy when dealing with numbers. I use

``if ( std::abs( a - b )      < std::abs( a ) * ( std::numeric_limits<float_t>::epsilon() * error_margin ) )  ``

where `float_t` is a typedef; this gives me as much precision as possible (assuming error_margin was calculated correctly) and allows easy adjustment to another type.

Furthermore, some floating-point values are not numbers: there's infinity, minus infinity, and of course not-a-number. `==` does funny things with those. Infinity equals infinity, but not-a-number does not equal not-a-number.

Finally, there are positive and negative zero, which are distinct but equal to each other! To separate them, you need to do something like check whether the inverse is positive or negative infinity. (Just make sure you won't get a divide-by-zero exception.)

So, unless you have a more specific question, I hope that handles itâ€¦

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »