You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One path here is to return another ProjectTo{SparseMatrixCSC} with different properties. With the adjoint, functions like rowvals(x') don't make sense, though. You can do this:
and sparse(x') ultimately calls copy(x') which calls SparseArrays.ftranspose((x').parent, x -> adjoint(copy(x)), Float64). Presumably they have put some thought into those methods, maybe this is OK? Then it's one line:
The other possible path is to construct a different projector, which tries to return another Adjoint{SparseMatrixCSC} instead. This is what already happens for adjoint vectors, and perhaps it's slightly awkward that we've used up the name ProjectTo{Adjoint} for this purpose:
julia> y =sprand(10, 0.2)'1×10adjoint(::SparseVector{Float64, Int64}) with eltype Float64:0.00.00.00.00.00.00.5543740.8619010.00.0
julia>ProjectTo(y)
ProjectTo{Adjoint}(parent =ProjectTo{SparseVector}(element =ProjectTo{Float64}(), nzind = [7, 8], axes = (Base.OneTo(10),)),)
julia>ans(ones(1,10))
1×10adjoint(::SparseVector{Float64, Int64}) with eltype Float64:0.00.00.00.00.00.01.01.00.00.0
Perhaps this could be more efficient than the first way. However, all of these sparse projections are pretty inefficient right now. They are more or less proof-of-concept implementations, awaiting someone with interest (and a use case!) to optimise them.
Consider:
cc @jieli-matrix
The text was updated successfully, but these errors were encountered: