full is a no-op on views of sparse objects

[Sacha0]

From discussion in JuliaLang/LinearAlgebra.jl#283. JuliaLang/LinearAlgebra.jl#231 is also relevant.

On views of SparseVectors and SparseMatrixCSCs, full falls back to full(x::AbstractArray) = x from 4ab4ba7/base/abstractarray.jl#L435. Hence

spvec = sparsevec([1], [1.0], 100)
cscmat = sparse([1, 1], [1, 2], [1.0, 1.0], 100, 2)

subspvec = sub(spvec, 10:20)
subcscmat = sub(cscmat, 10:20, 1:2)

println(typeof(subspvec))
println(typeof(subcscmat))

yields

SubArray{Float64,1,SparseVector{Float64,Int64},Tuple{UnitRange{Int64}},0}
SubArray{Float64,2,SparseMatrixCSC{Float64,Int64},Tuple{UnitRange{Int64},UnitRange{Int64}},0}

rather than dense copies as full does when operating directly on SparseVectors and SparseMatrixCSCs.

Glancing at the method for full(::AbstractSparseVector), I see two potential fixes: (1) write a method for full on views of SparseVectors, independent of full(::AbstractSparseVector); or (2) implement the operations on which full(::AbstractSparseVector) depends for views of SparseVectors, namely nonzeroinds and nonzeros, and either generalize AbstractSparseVector to include views of SparseVectors or generalize the signature of full(::AbstractSparseVector). Approach (2) is more generic, though chances are (1) would be easier.

Glancing at the method for full(::SparseMatrixCSC), I similarly see two potential fixes: (1) write a method for full on views of SparseMatrixCSCs independent of full(::SparseMatrixCSC); or (2) generalize full(::SparseMatrixCSC) such that it relies on nnz, nonzeros, rowvals, and nzrange rather than directly accessing the underlying SparseMatrixCSC data structure, implement those operations for views of SparseMatrixCSCs, and then generalize the signature of full(::SparseMatrixCSC). Again approach (2) is more generic, but in this case (1) is definitely easier.

Thoughts? Should this wait for resolution of JuliaLang/LinearAlgebra.jl#231?

Edit: Corrected ref. Thanks Tony!

[tkelman]

Note that it's good practice to hit y so github reloads a copy of the file where the url is replaced with the current sha. That way links to lines of code will remain relevant even in the future if that file changes.

I think this is a special case of JuliaLang/LinearAlgebra.jl#231 and we may as well start making progress on some pieces of it. I agree with your assessment that writing special methods would be the simpler place to start, but implementing more support for operating on views of sparse matrices would be more beneficial long-term.

[Sacha0]

I think this is a special case of JuliaLang/LinearAlgebra.jl#231 and we may as well start making progress on some pieces of it.

To confirm my understanding of JuliaLang/LinearAlgebra.jl#231, the plan is to deprecate full in favor of convert(Array, X), yes? Hence here the path forward would be to augment convert rather than full, yes?

[tkelman]

Either way. Plans need someone to start work on them and see how it goes, and if full isn't deprecated yet then it'll need to implement essentially the same operation as convert(Array, X) anyway.

[andreasnoack]

I think it's a fair conclusion from JuliaLang/LinearAlgebra.jl#231. It might also be worth noting that you can simply write Array(sv) instead of the more verbose convert(Array, sv) and since there was objections to a generic behavior for full, I don't think are reasons left for having the generic function full.

[KristofferC]

full is gone, seems this can be closed

[tkelman]

Is convert(Array, x) a no-op on views of sparse objects? If so, then the issue is not resolved.