# History of \`isapprox\` in languages

**URL:** <https://discourse.julialang.org/t/history-of-isapprox-in-languages/119347>\
**Category:** Numerics\
**Tags:** question, numerics, approx\
**Created:** [September 12, 2024, 6:51pm UTC](https://discourse.julialang.org/t/history-of-isapprox-in-languages/119347 "2024-09-12T18:51:09Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![Richard\_Fateman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/richard_fateman/32/212038_2.png) [@Richard\_Fateman](https://discourse.julialang.org/u/Richard_Fateman)\
**Post date:** [September 18, 2024, 7:58pm UTC](https://discourse.julialang.org/t/history-of-isapprox-in-languages/119347/26 "2024-09-18T19:58:20Z")

</div>

You are trying to grapple with the question of how to compare floating-point numbers, hoping that there a cure for “isapprox”. Lots of responses.  
Here’s mine.  
Don’t use it.  
That is, Google will find admonitions: Don’t compare floating point numbers for equality. “near equality” doesn’t make it easier.

Consider if what you intend by a particular use of isapprox(a,b) is  
-eps +a \< b \< eps+a or  
equivalently abs(a-b)\<eps  
where eps can be scaled,say by max(abs(a), abs(b),machine-epsilon) … or some other factor, depending on what you actually need. Defining to do it  
“for all cases” by isapprox() is implausible.

There are situations in which particular aspects of floating-point  
representation are examined by bit-twiddling subroutine libraries  
involving machine epsilon, Not-A-Number, extended precision, etc.  
Testing for exact or nearly corresponding bit patterns might have  
a use in such software, but typically done by experts in floating-point  
error analysis. There aren’t too many around in the community of language designers.  
Richard Fateman, UC Berkeley

---

_[View the full topic](https://discourse.julialang.org/t/history-of-isapprox-in-languages/119347)._