[aquarin]

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.

[Ace17]

> 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`).

[taneq]

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.

[TeMPOraL]

Floating point comparison is a bottomless pit. This article goes into details:

https://randomascii.wordpress.com/2012/02/25/comparing-float...

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.

[ladberg]

You should keep reading because he covers exactly that point soon after.