the semantics of storage[type]

[Sacha0]

One of full's meanings is: Given a matrix wrapped in a structured view type, for example a UnitLowerTriangular{Float64,SparseMatrixCSC{Float64,Int64}} L, return an instance of the storage type backing L, in this case a SparseMatrixCSC{Float64,Int64}, that is element-wise equal to L.

As with other meanings of full, till recently the plan has been to deprecate this meaning in favor of a convert call, in this case convert(storagetype(L), L) (with introduction of a storagetype function). But on a recent triage call, @JeffBezanson suggested that a storagetype-like function return an instance rather than a type.

Deciding the semantics of the storage[type] function is this issue's purpose. Should storage[type] return a type? Should storage[type] return an instance? If the latter, should storage[type] return an instance populated with the contents of the original AbstractArray? Or should storage[type] instead return an uninitialized instance (like similar), with the above meaning of full then spelt copy!(storage(L), L)? Best!

(Ref. past discussions in #17066, #17082, #17079, and #18850, and a recent mention in #23263.)

[Sacha0]

One potential hiccup with the return-uninitialized-instance semantics is immutable storage types.

[Keno]

Triage call suggests that storage is the wrong thing to think about here and the right abstraction is less special (i.e. algorithms are more likely to work), such that people writing generic matrix algorithms can write things like:

my_fancy_factorization(a::AbstractArray) = my_fancy_factorization(less_special(a))

and have it work, even for AbstractArrays that the person implementing the factorization doesn't know about (and similarly have matrix methods work fine, even when the people implementing custom AbstractArray types don't know about them). The precise naming and semantics of less special are of course at issue.

[Keno]

@JeffBezanson notes the similarity to promotion in scalar arithmetic.

[Sacha0]

Examples from base (linalg/triangular.jl and linalg/symmetric.jl) of the particular meaning of full that spurred this discussion:

+(A::UnitUpperTriangular, B::UnitLowerTriangular) = full(A) + full(B)
(*)(A::Tridiagonal, B::UpperTriangular) = A_mul_B!(full(A), B)
svdfact(A::AbstractTriangular) = svdfact(full(A))
A_mul_B!(C::AbstractMatrix, A::Tridiagonal, B::AbstractTriangular) = A_mul_B!(C, A, full(B))

[StefanKarpinski]

Indeed, perhaps this just needs a promotion-like mechanism for array types. I worry that "de-exiticize me by one 'notch'" would be pretty brittle and error prone. It seems like the kind of think that would mostly work and then not in many corner cases and just be an endless source of bugs and problems in generic code. The promotion mechanism is quite precise and Just Works™ once you have the right general promotion rules.

[Sacha0]

Deprecating full no longer depends on resolving this issue, and broad sentiment seems to favor deferring action on this or a similar abstraction till simultaneous resolution of #18161. (See discussion in #24147 and #24148.) So removing from the 1.0 milestone. Thanks all!