SA type aliases for constructors with precise eltype

[c42f]

The discussion at #655 has stimulated what I feel is finally a reasonable solution to constructing small static arrays with precise eltype without too much typing:

SA_F64 = SA{Float64}
SA_F32 = SA{Float32}

v = SA_F64[1,2,3]  # A Float64 vector

v = SA_F32[1 2; 3 4]  # A 2x2 Float32 SMatrix

I don't love the underscore there, but SAF64 looks very confusing. Other than that, I think the naming here is consistent with the precedent set by Base.ComplexF64.

Better naming options welcome!

I believe this (along with #633) finally fixes #24 to the extent that we can have a solution to that.

[andyferris]

I do have mixed feelings about the way it "looks". Also contrast with N0f8 (which might suggest SAf64?).

Do any other community members have some opinions on this?

[andyferris]

The other interesting case is ComplexF16, ComplexF32, ComplexF64.

[c42f]

The SAf64 alternative would be ok.

But I think the existing alternative is better because it really emphasizes the SA part separately. This is kind of important because we've chosen to overload the typed array construction syntax for this special tag type SA. (This is a consideration that doesn't exist for types like N0f8.)

julia> const SAf64 = SA_F64
SA{Float64}

julia> SA_F64[1,2,3]
3-element SArray{Tuple{3},Float64,1,3} with indices SOneTo(3):
 1.0
 2.0
 3.0

julia> SAf64[1,2,3]
3-element SArray{Tuple{3},Float64,1,3} with indices SOneTo(3):
 1.0
 2.0
 3.0

SAf64 kind of really runs the letters together there.

[c42f]

Does anyone have better ideas for naming or should we just merge this? I'd like to have something equivalent to it to go with SA in a new release.

Any further thoughts @andyferris; do you buy my argument or remain unconvinced? :-)

[c42f]

Well, unless anyone's inclined to paint this bikeshed a different color, I think I'll merge this tomorrow or so.

[c42f]

In the name of forward progress I went ahead and merged this; I think/hope these names are a good tradeoff!

[cdsousa]

Hi all,

Is a decrease in performance from using @StaticArray[] to using SA[] expected?

julia> using StaticArrays, BenchmarkTools

julia> f(x) = @SArray[1,2,x]

julia> g(x) = SA[1,2,x]

julia> @code_llvm f(3)
# short stuff

julia> @code_llvm g(3)
# long stuff

julia> @btime f(3)
  0.023 ns (0 allocations: 0 bytes)
3-element SArray{Tuple{3},Int64,1,3} with indices SOneTo(3):
 1
 2
 3

julia> @btime g(3)
  249.480 ns (2 allocations: 64 bytes)
3-element SArray{Tuple{3},Int64,1,3} with indices SOneTo(3):
 1
 2
 3

julia> versioninfo()
Julia Version 1.2.0
Commit c6da87ff4b (2019-08-20 00:03 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
Environment:
  JULIA_EDITOR = "/usr/share/code/code"

julia> import Pkg; Pkg.status("StaticArrays")
    Status `~/.julia/environments/v1.2/Project.toml`
  [90137ffa] StaticArrays v0.11.0 #master (https://github.com/JuliaArrays/StaticArrays.jl.git)

[c42f]

Is a decrease in performance from using @StaticArray[] to using SA[] expected?

Yikes no! Looks like I made a mistake of leaving in some spurious where T when refactoring which the tests did't pick up. Does #665 fix it for you?

[c42f]

By the way @cdsousa, thank you very much for reporting this problem.

These kind of performance problems are hard to detect without proper benchmarking, and proper benchmarking is hard without dedicated hardware... instead we rely heavily on @inferred, but sometimes (as in this case) @inferred can't be used to detect problems with inlining.

[cdsousa]

@c42f, it is fixed indeed! And thank you very much for all the awesome work.

[c42f]

Phew :-) You had me worried for a minute there (I did check this originally, but if I was mistaken it would nix the whole idea of having SA).