-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect results from isapprox
with Integer args
#55814
Comments
isapprox
isapprox
isapprox
isapprox
with Unsigned args
isapprox
with Unsigned argsisapprox
with Integer args
This diff --git a/base/floatfuncs.jl b/base/floatfuncs.jl
index 67e7899b410..ac482faafc2 100644
--- a/base/floatfuncs.jl
+++ b/base/floatfuncs.jl
@@ -226,13 +226,14 @@ function isapprox(x::Number, y::Number;
(nans && isnan(x) && isnan(y))
end
-function isapprox(x::Integer, y::Integer;
- atol::Real=0, rtol::Real=rtoldefault(x,y,atol),
+function isapprox(_x::Integer, _y::Integer;
+ atol::Real=0, rtol::Real=rtoldefault(_x, _y, atol),
nans::Bool=false, norm::Function=abs)
+ x, y = minmax(_x, _y)
if norm === abs && atol < 1 && rtol == 0
return x == y
else
- return norm(x - y) <= max(atol, rtol*max(norm(x), norm(y)))
+ return norm(y - x) <= max(atol, rtol*max(norm(x), norm(y)))
end
end should be enough to fix the order-dependent cases, right? Then the other problem is the overflowing of |
It could make sense to simply convert to |
Duplicate of #50380 |
I noticed the following results from
isapprox
:This function is documented to return
true
if the distance between the two inputs is within tolerance bounds, yet it returnsfalse
in the second case despite the fact that the two numbers are distance1
apart. In fact, it will returnfalse
even if the tolerance is increased:The same behavior occurs for relative tolerances:
Similar behavior can be seen for signed integers, where eg. 125 is considered to be within an absolute distance of 10 from -125:
This appears to be due to an integer overflow bug in the isapprox implementation for integer arguments. The generic implementation has a comment about avoiding integer overflow but no such accounting is done in the version specialized for integers.
The text was updated successfully, but these errors were encountered: