I have brief look at this book and it looks nice and easy to read, however I noted the author works with floating point numbers and in some places, you can see snippets like this:
// are the two points in the same location?
if (x1 == x2 && y1 == y2) {
return true;
}
You should never compare two floating-point numbers for equality.
Use interval and < > to determine if two numbers are close.
> You should never compare two floating-point numbers for equality.
... when their values come from an arithmetic computation.
Here's a counter example: Quake's collision code makes extensive use of `if(trace.fraction == 1.0f)`, which basically means "could the whole move be done without colliding?". This makes sense, because `fraction` is explicitly initialized to `1.0f`, and gets potentially overwritten with lower values in case the ray intersects colliders.
This could also make sense when dealing with clamped values, e.g:
```
const float ratio = clamp(some_computation, 0.0f, 1.0f);
if (ratio == 0.0)
{
// ...
}
```
In both cases, the zero or one being compared to isn't a result of an arithmetic computation ; it comes from an assignment with a known constant (e.g inside `clamp`).
Like a lot of things, the “don’t compare floats for equality” is a rule you should follow unless you understand it well enough to know when you can break it.
In particular, in many cases, you want to consider alternatives to comparing against a fixed epsilon: the relative epsilon approach, and the ULP (Units in the Last Place) method, which tests for how many other floats/doubles are representable between two values you're comparing. The benefit of these two methods is that they scale with the compared numbers.
// are the two points in the same location? if (x1 == x2 && y1 == y2) { return true; }
You should never compare two floating-point numbers for equality. Use interval and < > to determine if two numbers are close.