extend sparse broadcast to one- and two-dimensional Arrays, better version #20009
Conversation
Sacha0
added
sparse
|
Absent objections or requests for time, I plan to merge this Thursday morning PST. Best! |
|
No objections so far, looks like you can merge this, @Sacha0 |
| # combinations involving sparse arrays and PromoteToSparse collections continue in the promote-to-sparse funnel | ||
| promote_containertype(::Type{PromoteToSparse}, ::Type{AbstractSparseArray}) = PromoteToSparse | ||
| promote_containertype(::Type{AbstractSparseArray}, ::Type{PromoteToSparse}) = PromoteToSparse | ||
| # combinations involving Arrays and PromoteToSparse ecollections continue in the promote-to-sparse funnel |
| _spcontainertype{T<:AbstractArray}(::Type{T}) = AbstractArray | ||
| # need the following two methods to override the immediately preceding method | ||
| _spcontainertype{T<:StructuredMatrix}(::Type{T}) = PromoteToSparse | ||
| _spcontainertype{T<:SparseVecOrMat}(::Type{T}) = AbstractSparseArray |
There was a problem hiding this comment.
should this be only concrete SparseVecOrMat, or cover the entire corresponding abstract types?
There was a problem hiding this comment.
At present the outer (i.e. Broadcast's) container type promotion mechanism only funnels SparseVector and SparseMatrixCSC to sparse broadcast[!], so the inner (sparse broadcast[!]'s) container type promotion mechanism only need handle SparseVector and SparseMatrixCSC. Not capturing other <:AbstractSparseArray is intentional: sparse broadcast[!] isn't built to handle <:AbstractSparseArray that are not SparseVector or SparseMatrixCSC, there being no established interface for such <:AbstractSparseArrays.
If we want sparse broadcast[!] to handle combinations involving non-SparseVecOrMat <:AbstractSparseArray at this time, I can add a commit or open a separate PR promoting non-SparseVecOrMat <:AbstractSparseArray to SparseVector or SparseMatrixCSC as appropriate (as with structured matrices). Thoughts? Thanks!
There was a problem hiding this comment.
We should think through how the AbstractSparse types are used a bit, maybe not right here right now though. Anything that's assuming the exact CSC or concrete SparseVector data structures, fields, storage order etc should only be defined for those concrete types. But any other behavior we think should generically apply for all sparse arrays, I think it's worth widening some signatures and letting the definers of any concrete subtypes override more specific behaviors where they want.
I guess in this particular case the tradeoff would be between getting method errors vs dispatching to more generic dense behavior? The latter's likely better for now until we work out a better extensibility mechanism for how to get broadcast on custom array types to do interesting things.
There was a problem hiding this comment.
I guess in this particular case the tradeoff would be between getting method errors vs dispatching to more generic dense behavior? The latter's likely better for now until we work out a better extensibility mechanism for how to get broadcast on custom array types to do interesting things.
Yes, and agreed. (Though for the promotion approach to work, definition of convert([SparseVector|SparseMatrixCSC], UnknownSparseVectorOrMatrixType) alone should suffice.) Best!
Cheers, will merge once CI clears. (The latest change only touched a comment, but might as well.) Best! |
|
Go for it, @Sacha0! |
Like #20007, this pull request extends sparse
broadcast[!]to one- and two-dimensional Arrays (via promotion to sparse, as with structured matrices), addressing #11474. Unlike #20007, this pull request confines (to theSparseArrays.HigherOrderFnsmodule) changes that work around the issue described in #20007; it does not impact other consumers ofBroadcast. Best!