That seems pretty straightforward, yet when I try to use this it fails:
julia> m = zeros(3,3,3)
# output omitted
julia> SArray{size(m)}(m)
ERROR: TypeError: in SArray, in S, expected S<:Tuple, got Tuple{Int64,Int64,Int64}
Stacktrace:
[1] top-level scope at none:0
julia> isa(size(m), Tuple)
true
Julia seems mad at me for not giving it a tuple conveying the size as the manual instructs, however we can plainly see the size I pass in is a tuple. Where is my logic breaking down?
Thanks
It is however a valid and very julian optimization to construct the type describing the desired size outside of a long computation (via e.g. sz = Tuple{size(m)...}), and then have a function boundary into the long computation (e.g. expensive_stuff(m, other_args, ::Type{sz}) where sz). This way your long and expensive computation gets compiled for every size you pass in.
If you know the sizes at coding-time (e.g. you know that you want 3x3x3 tensors because 3d elasticity, or something) then you can of course just plug them in.
(actually, I think 2us is pretty fast for what we ask julia to do here)
Ok I did not expect to learn as many things as I did from this post, cool, guys. I think the biggest one was the difference between Tuple{3,3,3} and (3,3,3)… understanding that was enough to unstick me, thanks all.
Also, the first one is a pretty interesting parametric type: there could be no value x::Tuple{3,3,3}, but the language does not check type parameters so it’s OK, just like
The compiler gets to see the types, but not the values of variables. So this is in a sense just a trick to pass more information to the compiler.
For a normal Array{Int64,N} all it knows is the element type and the number of dimensions; the point of StaticArrays is that it also knows there will be exactly 3x3x3 elements here, allowing optimisations which make sense for 3 but not for a million.