force sym/herm back to return Matrix (1.6 inference fix)

[oxinabox]

Fixed the type inference failures we have been seeing in 1.6.
They show up because:

On 1.5:

julia> L = LowerTriangular(rand(3,3));

julia> U = UpperTriangular(rand(3,3));

julia> typeof(L .+ U')
Array{Float64,2}

On 1.6:

julia> L = LowerTriangular(rand(3,3));

julia> U = UpperTriangular(rand(3,3));

julia> typeof(L .+ U')
LowerTriangular{Float64, Matrix{Float64}}

Which honestly is kinda cool, but not what we want if we are to be type stable
Possibly we should push uplo into the type domain with a value type,
but that is beyond the scope of this PR.
The other branchs force the result to be a Matrix so the last should too

[willtebbutt]

Patch bump please :)

[mzgubic]

Thanks for solving this

[sethaxen]

Perhaps instead of converting to Matrix, it would be better to explicitly call parent if the produced cotangent is a LowerTriangular and then use tril!?

[oxinabox]

Perhaps instead of converting to Matrix, it would be better to explicitly call parent if the produced cotangent is a LowerTriangular and then use tril!?

We call Matrix in ther over branchs of this.

If there is a more efficient way should it be PRed to Base for convert ? (convert right now falls back to Matrix unless result is already a Matrix)
Possibly this code in all branchs should be rewritten to use convert to avoid copying in the case it is already a Matrix

[sethaxen]

We call Matrix in ther over branchs of this.

Oh you're right, then yes, this is fine. But a future PR should fix that.

Possibly this code in all branchs should be rewritten to use convert to avoid copying in the case it is already a Matrix

My suggestion is to avoid converting to Matrix at all. Certain non-Matrix types have good support for being wrapped with Symmetric, e.g. StaticMatrix. Maybe sparse matrices. So in the spirit of the discussion in #232 it would be good to avoid making the cotangent a Matrix. The idea would be to let broadcast sort it out but handle this potential type-instability by calling parent on an AbstractTriangular matrix. But this can be a future PR.

If there is a more efficient way should it be PRed to Base for convert ? (convert right now falls back to Matrix unless result is already a Matrix)

A more efficient way to do what?

[codecov-io]

Codecov Report

Merging #393 (cf106e7) into master (67c106f) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #393      +/-   ##
==========================================
- Coverage   98.49%   98.43%   -0.06%     
==========================================
  Files          22       22              
  Lines        1855     1857       +2     
==========================================
+ Hits         1827     1828       +1     
- Misses         28       29       +1     

Impacted Files	Coverage Δ
src/rulesets/LinearAlgebra/symmetric.jl	99.61% <100.00%> (ø)
src/rulesets/Base/fastmath_able.jl	98.24% <0.00%> (-0.88%)	⬇️
src/rulesets/LinearAlgebra/norm.jl	100.00% <0.00%> (ø)
src/rulesets/LinearAlgebra/factorization.jl	97.83% <0.00%> (+0.01%)	⬆️
src/rulesets/Base/evalpoly.jl	97.82% <0.00%> (+0.02%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 67c106f...cf106e7. Read the comment docs.