Kron of transpose/adjoint of sparse matrix with other sparse matrix becomes dense

[jebej]

This is because of the kron fallback for AbstractMatrix in LinearAlgebra catching the Transpose{Float64,SparseMatrixCSC{Float64,Int64}} matrix type.

This is a manifestation of the issue noted here #27586 (comment). I had tried a bunch of different signatures in that PR in order to switch to an abstract type instead of VecOrMat, but it caused an ambiguity with the LinearAlgebra method.

Note that this is a regression since 0.6 properly returned a sparse matrix by materializing the transpose/adjoint immediately instead of wrapping.

[jebej]

Example for experimentation: kron(adjoint(sprand(4,4,0.2)), sprand(4,4,0.2))

[fredrikekre]

kron(copy(adjoint(sprand(4,4,0.2))), sprand(4,4,0.2)) should work (and be equivlent to the 0.6 behavior).

[jebej]

kron(copy(adjoint(sprand(4,4,0.2))), sprand(4,4,0.2)) should work (and be equivlent to the 0.6 behavior).

Won't this copy unnecessarily if the matrix is dense?

[fredrikekre]

No? copy is how you materialize an adjoint/transpose wrapped matrix.

[jebej]

Ok I did the test, and because sparse ends up being called to create the sparse matrix for kron, it is more efficient to always copy an Adjoint or Transpose.

[jebej]

I guess that copy could be done automatically in the SparseMatrixCSC constructor, because calling the constructor directly on Adjoint or Transpose is slow.

[ViralBShah]

Anyone want to submit a PR for this one?

[ViralBShah]

It seems like #24980 could be revived.