You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As @johnmyleswhitepointed out when comparing the absolute difference with the eps() of the maximum value, the random arrays are usually different:
rseed(0)
t = 0
for x = 1:10000
x = rand(Float16, 10, 10)
y = rand(Float16, 10, 10)
if all(abs(x - y) .> eps(max(maximum(x), maximum(y))))
t += 1
end
end
t / 10000
In this case it is true 90.23 % of the time.
I found that the function in Base.Test to compute the tolerance for @test_approx_eq
You've hit upon a corner case for the default heuristic in @test_approx_eq; it simply isn't robust enough for general purpose comparisons. (Related: JuliaLang/LinearAlgebra.jl#67)
The following numerical experiment might help explain what's going on:
julia> x=rand(Float16,10^8);
julia> y=rand(Float16,10^8);
julia>norm(x-y,1) #sum of absolute differences overflowsInf16
julia>norm(x-y) JuliaLang/julia#2-normfloat16(4082.0)
julia>norm(x-y,Inf) #= max(abs(x-y)), the norm we actually usefloat16(1.0)
The l∞ norm is somewhat too robust to small perturbations, since it retains information only on the maximal difference; your use case is more of "death by a thousand cuts", as it were.
When testing approximate equality of Float16 arrays with @test_approx_eq from Base.Test on Julia 0.4 dev, the following produces no error:
However, for the Float32 case once should be sufficient to get an assertion error:
As @johnmyleswhite pointed out when comparing the absolute difference with the eps() of the maximum value, the random arrays are usually different:
In this case it is true 90.23 % of the time.
I found that the function in Base.Test to compute the tolerance for @test_approx_eq
will give a value of about 488.
The text was updated successfully, but these errors were encountered: