Incorrect results from `isapprox` with Integer args

[yurivish]

I noticed the following results from isapprox:

julia> isapprox(1, 2, atol=1)
true

julia> isapprox(UInt(1), UInt(2), atol=1)
false

This function is documented to return true if the distance between the two inputs is within tolerance bounds, yet it returns false in the second case despite the fact that the two numbers are distance 1 apart. In fact, it will return false even if the tolerance is increased:

julia> isapprox(UInt(1), UInt(2), atol=100)
false

julia> isapprox(UInt(1), UInt(2), atol=1_000_000)
false

The same behavior occurs for relative tolerances:

julia> isapprox(1, 2, rtol=1)
true

julia> isapprox(UInt(1), UInt(2), rtol=1)
false

julia> isapprox(UInt(1), UInt(2), rtol=100)
false

julia> isapprox(UInt(1), UInt(2), rtol=1_000_000)
false

Similar behavior can be seen for signed integers, where eg. 125 is considered to be within an absolute distance of 10 from -125:

julia> isapprox(Int8(125), Int8(-125), atol=10)
true

julia> isapprox(Int8(-125), Int8(125), atol=10)
true

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.

[giordano]

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 y - x, which can be caught by checking whether the difference is negative, but I don't know how to proceed after that, widening the two numbers?

[nsajko]

It could make sense to simply convert to AbstractFloat. But that would cause breakage in other places, e.g., for integers not representable as Float64.

[nsajko]

Duplicate of #50380