Closed sostock closed 2 years ago
Test code:
using LinearAlgebra, Random
Random.seed!(1234321)
H = UpperHessenberg(rand(5,5))
U = Bidiagonal(rand(5), rand(4), :U)
L = Bidiagonal(rand(5), rand(4), :L)
U\H
L\H # Error
( Array(U) \ Array(H) ) ≈ Array(U\H)
Array(L) \ Array(H)
julia> methods(\, (Bidiagonal, UpperHessenberg))
# 2 methods for generic function "\":
[1] \(A::Bidiagonal{var"#s814", V} where {var"#s814"<:Number, V<:AbstractVector{var"#s814"}}, B::AbstractVecOrMat{var"#s813"} where var"#s813"<:Number) in LinearAlgebra at C:\Users\woclass\AppData\Local\Programs\Julia-1.6.3\share\julia\stdlib\v1.6\LinearAlgebra\src\bidiag.jl:861
[2] \(A::Bidiagonal, B::AbstractVecOrMat{T} where T) in LinearAlgebra at C:\Users\woclass\AppData\Local\Programs\Julia-1.6.3\share\julia\stdlib\v1.6\LinearAlgebra\src\bidiag.jl:866
Not all return values are of the same type as B
.
Maybe we should move uplo
(upper/lower) to type parameter, or add 2 subtypes: BidiagonalU
, BidiagonalL
Did this come up in a real use case or are you systematically going through the possible combinations of special matrices? My gut feeling is that splitting Bidiagonal
in two isn't worth the overhead associated with introducing new types.
Did this come up in a real use case
I don’t think so, but I think it’s worth fixing regardless. We don’t need to introduce new types to fix this, but it would lead to more type stability since there are quite a few methods where different types are returned for different uplo
s, for example when multiplying a Bidiagonal
and an AbstractTriangular
.
For the Hessenberg
part of the OP, this should be fixed by #43779.
While
U\H
is actually ofUpperHessenberg
shape,L\H
is not and must return a fullMatrix
.Edit: It also happens for
UpperTriangular
instead ofUpperHessenberg
. ForUnitUpperTriangular
, it errors for both kinds ofBidiagonal
s.