narrow array conversions

[JeffBezanson]

Not all array types can convert from any AbstractArray via a 1-argument constructor call. Structured array types like Diagonal have different constructor behaviors, and some types like ReshapedArray don't have any such constructors.

fixes #26294, fixes #26178

[mbauman]

Wow, that was easier than I expected. I assume that this then hits the convert deprecation for ::Any for all custom arrays you've not explicitly allowed here?

[mbauman]

Did you try removing this one, too?

[mbauman]

Ah, nevermind. I was getting confused by Type{<:AbstractArray} and Type{AbstractArray}. This looks great. For anyone else getting into the same confusion, this dispatches to the AbstractArray{T}(…) constructor, which definitely exists and just copyto!s into a similar array.

[JeffBezanson]

From this I've discovered that it's possible to convert between sparse matrices and vectors (in the case of matrices, it checks that there's only one column). Other array types don't support that. Do we want to keep it?

[JeffBezanson]

Holy cow, this seems to have a huge effect on sysimg build time and size --- basecompiler.ji goes from ~19MB to ~80MB.

[JeffBezanson]

Ok, I thought this caused it but now I've seen the same behavior on master. Appears to be non-deterministic?

[StefanKarpinski]

Non-deterministic compiled code size has been reported a few times before.

[mbauman]

(#25900)

[mbauman]

I'm tentatively in support of having convert support moving between arrays of supported dimensionalities. See #23821.

[JeffBezanson]

OK, I agree that might be fine. I'll keep these methods for now then.

[nalimilan]

Probably worth marking #23821 for triage? It doesn't make much sense to keep these convert methods if we do not add more generic ones.

[JeffBezanson]

I'm finding the structured matrix constructors a bit hard to navigate. It's not clear when they (should?) check to see if their argument is representable. For example

julia> s = Symmetric(rand(3,3));
# allowed; virtually copies upper triangle to lower

julia> SymTridiagonal(s)
# allowed; ignores off-band elements

julia> tr = Tridiagonal(rand(3,3))
# allowed; ignores off-band elements

julia> SymTridiagonal(tr)
ERROR: ArgumentError: matrix cannot be represented as SymTridiagonal

This might be partly my fault from the constructor-to-convert fallback removal. But I'm guessing the intent is to have all such operations accessible as T(x), with the safe subset of those also callable via convert? That still doesn't seem totally optimal though. For example maybe the constructors should try harder to avoid throwing errors. Or maybe there's a pattern I'm missing of which operations are allowable?

[JeffBezanson]

#23821 should be non-breaking.

[nalimilan]

#23821 should be non-breaking.

Yes, it's non-breaking, but if we eventually decide not to do it, we won't be able to remove convert methods between sparse matrices and vectors, which will be an unjustified exception. So I'd rather remove these methods now.