JuliaArrays / JuliaArrays/StaticArrays.jl
Inconsistent output types of SMatrix solve with Vector/Matrix rhs
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 844
- Forks
- 159
- Avg merge
- 3d 21h
- Merged PRs (30d)
- 3
Description
Consider the following example:
P = @SMatrix [-0.5 0.5 0.5; 0.5 -0.5 0.5; 0.5 0.5 -0.5] # SMatrix{3,3,Float64,9}
w = rand(Float64, 3) # Vector{Float64}
W = rand(Float64, 3, 3) # Matrix{Float64}
println(typeof(P\w)) # => SArray{Tuple{3},Float64,1,3}
println(typeof(P\W)) # => Array{Float64,2}
i.e. doing a matrix solve with \(::SMatrix, ::Matrix) returns an ordinary matrix but a matrix solve with \(::SMatrix, ::Vector) returns a static vector. This seems surprising to me: I had expected both calls to return non-static/ordinary vectors/matrices (or at least the same "base" array type).
Here, \ calls into the generic (\)(A::AbstractMatrix, B::AbstractVecOrMat) from LinearAlgebra (at https://github.com/JuliaLang/julia/blob/cf410dc9e81cfa14a18ca3aef50346000b4615c7/stdlib/LinearAlgebra/src/generic.jl#L1102) which in turn calls into StaticArrays' \ method for LU decompositions at https://github.com/JuliaArrays/StaticArrays.jl/blob/64c64b2d808eed0b5751d080205ae2efe218f57e/src/lu.jl#L186-L187
So the issue seems to me that v[F.p] in the above converts v to an SVector (due to the indexing call), but B[F.p,:] is still an ordinary matrix due to the combination with :.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Vector and Matrix right-hand-side cases from the issue, then inspect the StaticArrays LU solve methods around src/lu.jl:186-187 and the generic LinearAlgebra method referenced in the report. Check how v[F.p] and B[F.p,:] are constructed, and add regression coverage showing consistent output types for both calls. Done means the two solve forms follow the same intended array-type behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- data
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100