It's OK to compare floating-points for equality
by coinfused on 4/14/2026, 4:00:49 PM
https://lisyarus.github.io/blog/posts/its-ok-to-compare-floating-points-for-equality.html
Comments
by: vouwfietsman
This explanation is relatively reductive when it comes to its criticism of computational geometry.<p>The thing with computational geometry is, that its usually <i>someone else's geometry</i>, i.e you have no control over its quality or intention. In other words, whether two points or planes or lines <i>actually align</i> or <i>align within 1e-4</i> is no longer really mathematically interesting because its all about the <i>intention of the user</i>: does the user think these planes overlap?.<p>This is why most geometry kernels (see open cascade) sport things like "fuzzy boolean operations" [0]) that <i>lean into epsilons</i>. These epsilons mask the error-prone supply chain of these meshes that arrive in your program by allowing some tolerance.<p>Finally, the remark "There are many ways of solving this problem" is also overly reductive, everyone reading here should really understand that <i>this is a topic that is being actively researched right now in 2026</i>, hence there are currently <i>no blessed solutions</i> to this problem, otherwise this research would not be needed. Even more so, to some extent this problem is fundamentally unsolvable depending on what you mean by "solvable", because your input is inexact not all geometrical operations are topologically valid, hence an "exact" or let alone "correct along some dimension" result cannot be achieved for all (combination of) inputs.<p>[0] <a href="https://dev.opencascade.org/content/fuzzy-boolean-operations" rel="nofollow">https://dev.opencascade.org/content/fuzzy-boolean-operations</a>
4/18/2026, 12:20:15 PM
by: jph
I have this floating-point problem at scale and will donate $100 to the author, or to anyone here, who can improve my code the most.<p>The Rust code in the assert_f64_eq macro is:<p><pre><code> if (a >= b && a - b < f64::EPSILON) || (a <= b && b - a < f64::EPSILON) </code></pre> I'm the author of the Rust assertables crate. It provides floating-point assert macros much as described in the article.<p><a href="https://github.com/SixArm/assertables-rust-crate/blob/main/src/assert_f64/assert_f64_eq.rs" rel="nofollow">https://github.com/SixArm/assertables-rust-crate/blob/main/s...</a><p>If there's a way to make it more precise and/or specific and/or faster, or create similar macros with better functionality and/or correctness, that's great.<p>See the same directory for corresponding assert_* macros for less than, greater than, etc.
4/18/2026, 11:14:21 AM
by: demorro
I guess I'm confused. I thought epsilon was the smallest possible value to account for accuracy drift across the range of a floating point representation, not just "1e-4".<p>Done some reading. Thanks to the article to waking me up to this fact at least. I didn't realize that the epsilon provided by languages tends to be the one that only works around 1.0, and if you want to use episilons globally (which the article would say is generally a bad idea) you need to be more dynamic as your ranges, and potential errors, increase.
4/18/2026, 11:33:52 AM
by: amelius
Think about this. It's silly to use floating point numbers to represent geometry, because it gives coordinates closer to the origin more precision and in most cases the origin is just an arbitrary point.
4/18/2026, 12:32:41 PM
by: mizmar
There is another way to compare floats for rough equality that I haven't seen much explored anywhere: bit-cast to integer, strip few least significant bits and then compare for equality. This is agnostic to magnitude, unlike epsilon which has to be tuned for range of values you expect to get a meaningful result.
4/15/2026, 5:38:28 AM
by: 4pkjai
I do this to see if text in a PDF is exactly where it is in some other PDF. For my use case it works pretty well.
4/18/2026, 10:47:11 AM
by: AshamedCaptain
One of the goals of comparing floating points with an epsilon is precisely so that you can apply these types of accuracy increasing (or decreasing) changes to the operations, and still get similar results.<p>Anything else is basically a nightmare to however has to maintain the code in the future.<p>Also, good luck with e.g. checking if points are aligned to a grid or the like without introducing a concept of epsilon _somewhere_.
4/18/2026, 11:27:31 AM