It's NOT OK to compare floating-points using epsilons
18 points by intarga
18 points by intarga
Although I am not a fan of comparing floats using epsilons myself, I think it is good to read a defence of the idea written by people who have thought about this idea deeply, and who have done far more analysis than the OP.
The APL language has a concept of "tolerated comparison", which is like using an epsilon, but which uses a different formula than the OP, because it is quite tricky to implement this idea "correctly". In short, the epsilon used is not the same value for every comparison: it depends on the values being compared.
The problem is that these epsilons are pretty much always simply guessed, and there is no correct way to choose one epsilon out of many. If you have several such comparisons, no combination of epsilons will ensure that everything works correctly.
APL addresses this, by automatically computing an epsilon based on the magnitude of the values being compared. But:
Another problem with epsilons is that such comparison isn't transitive.
APL tolerated comparison isn't transitive, and I have a beef with this.
APL tolerated comparison isn't transitive, and I have a beef with this.
I have thought about this a little bit! If it’s transitive then it can’t be tolerant everywhere.
If it’s transitive, then there must be equivalences classes, like islands, which must have boundaries. Points on a boundary can’t tolerate any error, at least in the direction that nudges it into the next island.
Conversely if every point has some neighborhood of values near it that it compares equal to, then comparison can’t be transitive—because the overlapping neighborhoods would chain together and make everything equal.
Thanks for posting this here. It's a good read!