Unable to sum ::SparseVector{Num,Int} s

[abraunst]

From https://discourse.julialang.org/t/is-there-a-defined-minimal-interface-for-a-type-to-work-with-sparsearrays/69602/2

using Symbolics, SparseArrays

@variables a
v = sparsevec([1], [a])
v+v #  throws 

[jlapeyre]

SparseArrays would benefit from checking for the unstored value in a uniform way. Perhaps always using iszero. But, accommodating Symbolics should play no part in deciding how to do this.

Symbolics doesn't follow the documented and de facto semantics of == and iszero. This makes it very difficult for packages to interoperate with Symbolics. Symbolics needs to adapt to the ecosystem, rather than the other way around.

For example, the docstring for iszero says "Return true if x == zero(x)". But,

julia> using Symbolics

julia> @variables x
1-element Vector{Num}:
 x

julia> iszero(x)
false

julia> x == zero(x)
x == 0

Opening an issue in Symbolics on how to fix this might be useful.

[jlapeyre]

I can't find this addressed directly in the Symbolics.jl repo. But this blog post suggests that the behavior of the code in my comment above is desirable for something other than facilitating generic programming (you can read about it there). At any rate, it is a conscious decision. At first glance, I would have said it's better to construct an equation expression with a different function (not ==), leaving == free to follow documented semantics. At any rate it is still better to clean up SparseArrays with reference to standard Julia. If this allows it to work with Symbolics, fine. That's a bonus.

[abraunst]

In any case, it's rather arbitrary to draw the line between x == zero(x) and iszero(x) (which should be semantically equivalent). We could (and probably will) modify the SparseArrays code to use the latter instead of the former, but I wouldn't be surprised if in the future Symbolics makes iszero(x::Num) return a Num...

[ViralBShah]

Should be moved to SparseArrays.jl