Transposing nx0 or 0xn SMartix yields empty Union as element type

[janbruedigam]

I am having issues when transposing an SMatrix with a zero dimension. When transposing this matrix, the element type changes to Union{}. This happens with either one of the 2 dimension being zero, and also with other types (e.g. Int64).

This issue came up using v0.12.3 and v0.12.2. In v0.12.1 the element type stays the same, which I think is the expected and desired behavior.

Minimum (not) working example using v0.12.3 (and v0.12.2):

julia> using StaticArrays

julia> a = SMatrix{3,0,Float64,0}()
3×0 SArray{Tuple{3,0},Float64,2,0} with indices SOneTo(3)×SOneTo(0)

julia> a'
0×3 SArray{Tuple{0,3},Union{},2,0} with indices SOneTo(0)×SOneTo(3)

Working example using v0.12.1:

julia> using StaticArrays

julia> a = SMatrix{3,0,Float64,0}()
3×0 SArray{Tuple{3,0},Float64,2,0} with indices SOneTo(3)×SOneTo(0)

julia> a'
0×3 SArray{Tuple{0,3},Float64,2,0} with indices SOneTo(0)×SOneTo(3)

[andyferris]

Hmm... yeah since we removed our reliance on type inference from StaticArrays (for important correctness and non-crashiness reasons) so we can't really ask the question "what type would the elements have had if there were some elements?" anymore. So many functions on empty arrays return an array with element type Union{}.

It would be possible to overload this for Number, since we know how adjoint and transpose work on those. Note that these functions are recursive so it's not correct to preserve the element type in the general case. So this just kicks the can down the road... I'm sure that someone will have a 0xn block matrix they want to transpose eventually!

The other approach is to embrace the Adjoint and Transpose wrappers more fully.

[janbruedigam]

That argument makes sense to me:

Hmm... yeah since we removed our reliance on type inference from StaticArrays (for important correctness and non-crashiness reasons) so we can't really ask the question "what type would the elements have had if there were some elements?" anymore.

The reason where this issue came up for me was when multiplying an nxm matrix with a vector of dimension m. The m dimension varies depending on the situation and can also be zero in which case the matrix vector product used to be a zero vector of dimension n (which is also somewhat debatable come to think of it). Now I get an error where I think from a practical standpoint the product should exist (whether it's an n dimensional zero vector or an nx0 matrix). But yeah, also not sure what the best approach is.

julia> A = SMatrix{0,3,Float64,0}()
0×3 SArray{Tuple{0,3},Float64,2,0} with indices SOneTo(0)×SOneTo(3)

julia> b = SVector{0,Float64}()
0-element SArray{Tuple{0},Float64,1,0} with indices SOneTo(0)

julia> A'*b
ERROR: MethodError: zero(::Type{Union{}}) is ambiguous. Candidates:
  zero(::Type{T}) where T<:Number in Base at number.jl:242
  zero(::Union{Type{P}, P}) where P<:Dates.Period in Dates at C:\Users\janbr\AppData\Local\Programs\Julia\Julia-1.4.1\share\julia\stdlib\v1.4\Dates\src\periods.jl:50
  zero(a::Type{SA}) where SA<:StaticArray in StaticArrays at C:\Users\janbr\.julia\packages\StaticArrays\mlIi1\src\linalg.jl:88
Possible fix, define
  zero(::Type{Union{}})
Stacktrace:
 [1] macro expansion at C:\Users\janbr\.julia\packages\StaticArrays\mlIi1\src\matrix_multiply.jl:50 [inlined]
 [2] _mul at C:\Users\janbr\.julia\packages\StaticArrays\mlIi1\src\matrix_multiply.jl:37 [inlined]
 [3] *(::SArray{Tuple{3,0},Union{},2,0}, ::SArray{Tuple{0},Float64,1,0}) at C:\Users\janbr\.julia\packages\StaticArrays\mlIi1\src\matrix_multiply.jl:8
 [4] top-level scope at REPL[11]:1

[c42f]

since we removed our reliance on type inference from StaticArrays

Actually they got put back in for map/broadcast over zero sized collections so that people wouldn't keep encountering these edge cases. The reasoning being that Base also commits the same crime ;-)

So possibly we could fix this a similar way.