Floating point imprecision with tests in Atom REPL
When i run test Multitaper
from the Atom / Juno REPL, it errors out. With different errors, though (see below). When i run test either with julia test/runtest.jl
or julia -e 'import Pkg; Pkg.build(); Pkg.test("Multitaper"; coverage=true)'
from bash, it runs fine. So i tried import Pkg; Pkg.build(); Pkg.test("Multitaper"; coverage=true)
from the REPL, but it errors out. There seems to be an issue with Atom/Juno.
Spectrum analysis with gaps: Test Failed at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:34
Expression: ((out[1])[1]).S[end - 5:end] ≈ [0.14565610885883232, 0.13580424778417852, 0.1293182864247158, 0.1395702616312291, 0.1664040092175493, 0.09202992618124456]
Evaluated: [0.14543356846811006, 0.13562233447778846, 0.12902790267062653, 0.1390735544250517, 0.16571108838230617, 0.09180531734079359] ≈ [0.14565610885883232, 0.13580424778417852, 0.1293182864247158, 0.1395702616312291, 0.1664040092175493, 0.09202992618124456]
Stacktrace:
[1] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:34
[2] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1115
[3] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:34
Spectrum analysis with gaps: Test Failed at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:41
Expression: (out1[2])[end - 5:end] ≈ [17.444104148892166, 17.408259466237617, 17.382026447855413, 17.422494161582264, 17.506998428080035, 17.170675010806065]
Evaluated: [17.444213771865872, 17.40836462891643, 17.395835313061312, 17.422698686063306, 17.50720418110945, 17.170799445545875] ≈ [17.444104148892166, 17.408259466237617, 17.382026447855413, 17.422494161582264, 17.506998428080035, 17.170675010806065]
Stacktrace:
[1] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:41
[2] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1115
[3] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:34
Spectrum analysis with gaps: Test Failed at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:45
Expression: (out1[1]).Fpval[end - 5:end] ≈ [0.16807947246930965, 0.09822111646921738, 0.0341711343274661, 0.4933223598055142, 0.9312676978366197, 0.7307073177440282]
Evaluated: [0.16807735168842242, 0.09821956726975023, 0.03406832345614996, 0.49331774315244115, 0.9312668180688901, 0.7307054384542364] ≈ [0.16807947246930965, 0.09822111646921738, 0.0341711343274661, 0.4933223598055142, 0.9312676978366197, 0.7307073177440282]
Stacktrace:
[1] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:45
[2] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1115
[3] top-level scope at /home/user/.julia/packages/Multitaper/qFw26/test/mdmwps_test.jl:34
Test Summary: | Pass Fail Total
mdmwps multitaper | 6 3 9
Slepians with gaps | 1 1
Spectrum analysis with gaps | 2 3 5
Coherence with gaps | 1 1
Generalized Slepians | 2 2
Consider Travis is fine, the errors the REPL throws all boil down to float imprecision, i'd say it's my machine, your package is not to blame, and tests do pass. @anowacki recommended to define atol/rtols. He is probably right. Although this imprecision does not occur when i run the test from bash, this can point to a general problem with floats when using the package in the Juno REPL. I am not sure whether it is something with JUNO. Could anyone but me even replicate this issue?
Comments (1)
-
reporter - Log in to comment
I just tried starting julia from bash, and simply running
test Multitaper
runs also fine. So it’s not the REPL per se. It really looks as if there is a problem with floating point precision in Juno. One fix could be to replace≈
withisapprox
and specify tolerances. Considering https://docs.julialang.org/en/v1/base/math/#Base.isapprox: The default atol is zero and the default rtol depends on the types of x and y it seems as if my Juno messes up the types.Anyways, as long as no one can replicate this issue, and there is a practical solution anyways, we can also let if be.