Fix #356, Performance of SMatrix(::StaticMatrix)

[tkoolen]

Fixes #356.

[codecov-io]

Codecov Report

Merging #357 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #357   +/-   ##
=======================================
  Coverage   93.36%   93.36%           
=======================================
  Files          37       37           
  Lines        2713     2713           
=======================================
  Hits         2533     2533           
  Misses        180      180

Impacted Files	Coverage Δ
src/SMatrix.jl	94.78% <100%> (ø)	⬆️

---

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 9044eb2...1e323f9. Read the comment docs.

[coveralls]

Coverage remained the same at 93.365% when pulling 1e323f9 on tkoolen:tk/fix-356 into 9044eb2 on JuliaArrays:master.

[c42f]

This fix looks functional, but perhaps we should just be deleting this method entirely, and fixing the equivalent SArray constructor instead?

(This has the feeling of a lot of other issues we've had in StaticArrays ever since SMatrix became a simple type alias of SArray.)

[tkoolen]

I finally got around to this again. What do you think of the new approach?

It currently requires defining a convert_similar_type method for each StaticArray subtype that needs to work with these generic StaticArray constructor methods. I wanted to just use similar_type, but for this purpose it's too inconsistent in whether it returns an MArray or SArray type. Unfortunately, it's not possible to define convert_similar_type generically for all possible subtypes of StaticArray, because in general it isn't even known how many type parameters any given concrete StaticArray subtype has.

[andyferris]

OK, interesting approach. I can see that we need something like this. (I wonder if Julia v0.7 includes any implementation for controlling eltypes for AbstractArray?)

Unfortunately, it's not possible to define convert_similar_type generically for all possible subtypes of StaticArray, because in general it isn't even known how many type parameters any given concrete StaticArray subtype has.

We used to have a hilarious implementation for exactly this, that would analyze the type tree to the point where it could replace exactly the correct type parameters as necessary. :)

[c42f]

It looks like #356 was closed by taking a much more minimal approach in #358. Should we close this issue?

[tkoolen]

Sure.