problem with StaticArrays and \

[tpapp]

(I reported this issue at ForwardDiff.jl where I was told it is an issue with StaticArrays, so I am opening one here.)

Using Julia 1.0.0, [f6369f11] ForwardDiff v0.9.0, [90137ffa] StaticArrays v0.8.3, the following MWE

import ForwardDiff
using StaticArrays

function f(M, Tws, μs)
    Twμs = Tws .* μs
    mx = SMatrix{2,2}(M + Tws[2], -Twμs[2], -Twμs[1], M + Tws[1])
    mx \ Twμs
end
M = 1.0
Tws = SVector(2.0, 2.0)
μs = SVector(0.5, 0.5)
f(M, Tws, μs)                   # works
ForwardDiff.jacobian(μs -> f(M, Tws, μs), μs) # gives the error below

gives

julia> ForwardDiff.jacobian(μs -> f(M, Tws, μs), μs)
ERROR: MethodError: no method matching Float64(::ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2})
Closest candidates are:
  Float64(::Real, ::RoundingMode) where T<:AbstractFloat at rounding.jl:185
  Float64(::T<:Number) where T<:Number at boot.jl:725
  Float64(::Int8) at float.jl:60
  ...
Stacktrace:
 [1] convert(::Type{Float64}, ::ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2}) at ./number.jl:7
 [2] macro expansion at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/util.jl:11 [inlined]
 [3] convert_ntuple at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/util.jl:8 [inlined]
 [4] SArray{Tuple{2,2},Float64,2,4}(::Tuple{Float64,ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2},ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2},Float64}) at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/SArray.jl:28
 [5] convert at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/convert.jl:8 [inlined]
 [6] det at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/det.jl:4 [inlined]
 [7] solve(::Size{(2, 2)}, ::Size{(2,)}, ::SArray{Tuple{2,2},Real,2,4}, ::SArray{Tuple{2},ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2},1,2}) at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/solve.jl:8
 [8] \ at /home/tamas/.julia/packages/StaticArrays/Ze5H3/src/solve.jl:1 [inlined]
 [9] f(::Float64, ::SArray{Tuple{2},Float64,1,2}, ::SArray{Tuple{2},ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2},1,2}) at ./REPL[11]:4
 [10] (::getfield(Main, Symbol("##3#4")))(::SArray{Tuple{2},ForwardDiff.Dual{ForwardDiff.Tag{getfield(Main, Symbol("##3#4")),Float64},Float64,2},1,2}) at ./REPL[16]:1
 [11] static_dual_eval at /home/tamas/.julia/packages/ForwardDiff/hnKaN/src/apiutils.jl:30 [inlined]
 [12] vector_mode_jacobian(::getfield(Main, Symbol("##3#4")), ::SArray{Tuple{2},Float64,1,2} at /home/tamas/.julia/packages/ForwardDiff/hnKaN/src/jacobian.jl:172
 [13] jacobian(::Function, ::SArray{Tuple{2},Float64,1,2}) at /home/tamas/.julia/packages/ForwardDiff/hnKaN/src/jacobian.jl:81
 [14] top-level scope at none:0

[jrevels]

Non-ForwardDiff MWE:

julia> StaticArrays.arithmetic_closure(Real)
Float64

This is incorrect assuming the given definition of StaticArrays.arithmetic_closure:

 Return the type which values of type T will promote to under a combination of the arithmetic operations +, -, *
  and /.

[andyferris]

There's not much test coverage (nor practical use case, to be honest, given the focus here is speed) for static arrays of abstract eltype, sorry.

I'm assuming we can fix up arithmetic_closure pretty easy. Honestly though, this kind of function should live in the same file or module that defines Number... is there something better existing in Base or LinearAlgebra?

[bjack205]

I'm getting a separate issue with the \ operator and static arrays. I've gotten this error message a few times:

setindex!(::SArray{Tuple{1,4},Float64,2,4}, value, ::Int) is not defined.

Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] setindex!(::SArray{Tuple{1,4},Float64,2,4}, ::Float64, ::Int64) at /home/bjack205/.julia/packages/StaticArrays/Ze5H3/src/indexing.jl:3
 [3] macro expansion at /home/bjack205/.julia/packages/StaticArrays/Ze5H3/src/indexing.jl:49 [inlined]
 [4] _setindex!_scalar at /home/bjack205/.julia/packages/StaticArrays/Ze5H3/src/indexing.jl:37 [inlined]
 [5] setindex! at /home/bjack205/.julia/packages/StaticArrays/Ze5H3/src/indexing.jl:33 [inlined]
 [6] ldiv!(::Diagonal{Float64,Array{Float64,1}}, ::SArray{Tuple{1,4},Float64,2,4}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v0.7/LinearAlgebra/src/diagonal.jl:326
 [7] \ at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v0.7/LinearAlgebra/src/diagonal.jl:445 [inlined]
 [8] \(::Adjoint{Float64,Array{Float64,2}}, ::SArray{Tuple{1,4},Float64,2,4}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v0.7/LinearAlgebra/src/generic.jl:862
 [9] macro expansion at ./show.jl:556 [inlined] (repeats 2 times)
 [10] backwardpass_sqrt!(::TrajectoryOptimization.ConstrainedResultsStatic{4,1,2,4}, ::Solver) at ./In[49]:70
 [11] top-level scope at util.jl:156
 [12] top-level scope at In[50]:2

It appears to happen when one of the matrices has a diagonal structure, but I can't always replicate it. I'm using it in a code base where diagonal matrices are common (but not guaranteed). I'm guessing this is an issue with StaticArrays since the operation works just fine most of the time and works when I convert the offending matrices to normal Arrays.

[c42f]

@bjack205 looks like a separate problem. Can you open a new issue, including which version of julia you're using, and, if possible the code which leads to the stacktrace above? It looks like the official version of 0.7 for linux64 from the stack trace, is that right?

My attempt at a reproduction led to the following MWE which is obscure and strangely shaped, though valid:

Diagonal([1.0]) \ @SMatrix [1.0 2.0]

[jrevels]

There's not much test coverage (nor practical use case, to be honest, given the focus here is speed) for static arrays of abstract eltype, sorry.

It was StaticArrays in the first place that generated the SMatrix with abstract eltype, see #497

[tpapp]

@andyferris: I have started a package to address the functionality of StaticArrays.arithmetic_closure, https://github.com/tpapp/AlgebraResultTypes.jl/ . It has no dependencies and is kept minimal, but I will strive to keep it extensively tested (both with random and deterministic tests for various combinations of types).

Once registered, would you be open to a PR that replaces arithmetic_closure with the functionality in that package?

[andyferris]

OK interesting.

I don't have a particular problem with that (though it is nice having zero deps). I have a broader comment - if you feel the abstraction you've created is correct, and is useful for package authors, should we look at moving it to Base? There has been a longstanding issue about Number not having any documented interface guarantees (e.g. is it a ring?)

[tpapp]

I agree that the long run solution should perhaps live in Base (even though testing the combination of various things is nice), but I think that refining and testing the approach for a while outside Base has its benefits.

[c42f]

A bisect shows this appears to have been fixed a while ago in #503 by @andyferris. Nice one Andy :-)