Sure, one relatively easy way to do this with an arbitrary tolerance might be with isapprox. For example:
julia> A = fill(-2.6e-9, 5,5)
5×5 Matrix{Float64}:
-2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9
-2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9
-2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9
-2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9
-2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9 -2.6e-9
julia> map!(x -> isapprox(x, 0, atol=1e-8) ? 0 : x, A, A)
5×5 Matrix{Float64}:
0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0
Note that doing this with map! will not allocate, so should be quite efficient:
julia> @btime map!(x -> isapprox(x, 0, atol=1e-8) ? 0 : x, $A, $A)
30.984 ns (0 allocations: 0 bytes)
if you don't specify a tolerance (what the atol option is doing above) it will choose a reasonable default for general floating point work using a somewhat complicated formula:
isapprox(x, y; atol::Real=0, rtol::Real=atol>0 ? 0 : √eps, nans::Bool=false[, norm::Function])
Inexact equality comparison. Two numbers compare equal if their relative distance or
their absolute distance is within tolerance bounds: isapprox returns true if norm(x-y)
<= max(atol, rtol*max(norm(x), norm(y))). The default atol is zero and the default
rtol depends on the types of x and y. The keyword argument nans determines whether or
not NaN values are considered equal (defaults to false).
For real or complex floating-point values, if an atol > 0 is not specified, rtol
defaults to the square root of eps of the type of x or y, whichever is bigger (least
precise). This corresponds to requiring equality of about half of the significand
digits. Otherwise, e.g. for integer arguments or if an atol > 0 is supplied, rtol
defaults to zero.
As to whether anything is going wrong in your previous calculations: not necessarily, given that rounding error is an unavoidable part of working with fixed-precision floating point numbers. However -2.6e-9 does sound a bit large compared to
julia> eps(0.0)
5.0e-324
so it depends on what exactly you're doing. If you're, e.g., subtracting two large but similar floats from each other, then this level of error might not be surprising for Float64s