Brevity and StaticArrays

#1

I like StaticArrays – the ability to say, “The type of this variable is a matrix with such-and-such a size.” I also love how powerfully brief my code can be in Julia, allowing me to stay very “mathy”, using LaTeX characters, like \times for cross product.

Call it vain, but I wish there were a briefer way to create a StaticArray, like regular old brackets. Writing out the whole word SVector interferes with the flow. I like how I can specify an IPv4, for instance, as ip"127.0.0.1". Could something like this work for StaticArrays, but with brackets? Like:

x = s[1.; 2.; 3.] # It's an SVector!

Or maybe we could use some other type of bracket or something.

Does this make sense? Does Julia support creations like this, or would Julia have to change to facilitate it? Or is there already a brief way to specify StaticArrays that I don’t see in the StaticArrays doc?

#2

This PR would let you do @s[1.;2.;3.].

#3

Thanks. That’s an interesting PR, with a similar motivation to my own. I’m not sure writing a macro for every array construction feels right to me though. In this case, I think a type alias is clearer.

Macro method (assuming that PR goes in):

x = @s[1.; 2.; 3.]      # where @s was defined somewhere to use @SVector

Type alias:

x = s(1., 2., 3.)     # where s = SVector was defined somewhere

Regular:

x = SVector(1., 2., 3.)

But I dearly wish I could use square brackets instead.

Proposed:

x = s[1.; 2.; 3]

This would require that the s[ ... ] pattern could be parsed.

#4

The problem is that s[1, 2, 3] (or, equivalently, s[1; 2; 3]) is already parsed and has a well-defined meaning: it gives you a vector with element type s initialized to [1, 2, 3]. So we have

julia> Float64[1, 2, 3]
3-element Array{Float64,1}:
 1.0
 2.0
 3.0

Thus, if you have s = SVector{3, Float64}, and you try to do s[1, 2, 3], you’re asking for a vector of SVectors (this fails because you can’t convert an integer to an SVector).

So the closest you can get is with that PR mentioned above and something like @s[1, 2, 3], since the macro can insert the appropriate syntax to do what you want.

#5

Thanks @rdeits. I never use that syntax and had forgetten about it. You’re right that that’s devastating to my proposal. Do you have any alternate proposal? Different brackets? Some other clever idea?

#6

Personally I would go for SVector(1, 2, 3) or

svec(x...) = SVector(x...)
svec(1, 2, 3)

I realize it’s not as concise as [1, 2, 3] but I’ve found that I personally don’t mind it too much.

One other thing you could do if you really want is create a macro that turns all instances of s[1, 2, 3] into SVector(1, 2, 3) within a particular block of code. That will give you the brevity you’re looking for, at the cost of making your code harder for others to understand.

#7

I had thought about this a lot.
The typed array gets it behavior from the definitions

getindex(::Type{T}, vals...) = .......
typed_hcat(::Type{T}, vals...) = .......
typed_hvcat(::Type{T}, vals...) = .......

I thought that maybe one could define something like

getindex(::Type{Type{T}}, vals...) where T<:StaticArray = ......
typed_hcat(::Type{Type{T}}, vals...) where T<:StaticArray = ......
typed_hvcat(::Type{Type{T}}, vals...) where T<:StaticArray = ......
const S = Type{SArray}

and use as

S[1, 2, 3]
S[1 2 3]
S[1 2; 3 4]

But with this I find some drawbacks in the generated native code, especially in the typed_hvcat case.
Anyway, I guess those code generations are fixable.

#8

I’d love to see something like this work:

⟦1, 2, 3⟧
⟦1, 2; 3, 4⟧
#9

There’s also the issue of having a concise way to write literal static matrices…

#10

So people don’t like something like @SA[1, 2, 3]? I would have guessed this is short enough.

We can do sa[1, 2, 3] if sa is not a type, but say some singleton instance created for just this case.

I’ve been thinking more generally… it would be nice to have some more generalised “container literal” syntax like @DF[a = [1, 2, 3], b = [4, 5, 6]] for a DataFrame, or whatever. Apart from macros I’m not sure how to proceed…

#11

After thinking about all those options I started to really like @stuff[...], thas why I went for the PR.