Naming for small vectors

[c42f]

As discussed at SimonDanisch/FixedSizeArrays.jl#159, I rather liked writing Vec and Mat for small sized arrays in FixedSizeArrays. Perhaps we should try to recover these names for StaticArrays, perhaps not?

Note that SIMD.jl has also started using Vec so there is unfortunately already a naming clash with FixedSizeArrays there @eschnett

[andyferris]

Also interesting: SIMD.jl is probably closer to VecElement which is in Base.

[andyferris]

OK, I'll respond with the history of my decision and we can work on the future from there:

• I wanted to do multidimensional arrays, but Arr seems kinda silly. It's nice to have something as close to typealias SVector{T} SArray{T,1} as possible but I didn't manage to get there because there are only a small set of operations allowed in a type alias and SArray has a complicated parameter structure (if we can address this over time that is good).
• There is a history of other packages like ArrayFire.jl has AFArray and DistributedArrays.jl has DArray (each with AFVector and DVector, etc) so it's becoming a little idiomatic in Julia to name things this way.
• Being careful not to have a package race/war to see who can claim Vec and Mat first (back then I didn't want to clash with FixedSizeArrays either.)
• There is more than one prefix for different types of object, like SArray and MArray. I'm thinking something like PArray or PtrArray for a pointer-based, fixed-size array.
• For the sake of being verbose rather than concise (people who know Julia but not StaticArrays.jl might guess that SVector behaves quite similarly to Vector).

[eschnett]

The name VecElement in Base was chosen because it is shorter than SIMDVectorElement, and because it is more descriptive than VecEl.

If there is an overall consistent naming scheme, then renaming SIMD's types is not out of the question.

[c42f]

Yes, all valid points.

On the subject of verbosity, I feel that Vec is something that gets typed rather a lot, so I'd consider the "small names for commonly used things" rule applies in this case. I also like the "short names for short vectors" pun ;-)

What's the idea behind PArray vs MArray?

[andyferris]

@eschnett SIMDElement ?

@c42f Would a typealias for Vec be useful?

What's the idea behind PArray vs MArray?

Well, it could be used for C interop (or non-garbage collected arrays with Base.Libc.malloc() etc) or for a hack I'm planning for getting a stack pointer using an LLVM call which allocates stack space and calls a Julia function (allocating an extra stack frame should be faster than garbage collection or even malloc/free, though not as fast as Julia just letting me have a damn stack pointer!).

[andyferris]

In other words, PArray should be fast like SArray and mutable like MArray.

[c42f]

Oh I see - PArray is an array with a bare pointer inside (user to manage the memory). The compiler will probably (?) have limited insight into that if it's stack allocated in an LLVM call so codegen may not be so good. But it's worth a go, a stack allocated mutable buffer of some kind would be really useful in some cases.

I'm not sure about a typealias in the long run - I think that'll just lead to syntactic fragmentation among users of the library and cause confusion. Could be useful in the short term to see how things will play out.

[andyferris]

Could be useful in the short term to see how things will play out.

There's always using StaticArrays.FixedSizeArrays for the short term. You can already use Vec there.

[SimonDanisch]

Well, last year using pointers was a disaster for codegen... And since the compiler devs are discouraging the use of pointers, I'd be surprised if this changed substantially ;) Also, things get ugly very quickly :-D I just hope this damn mutable tuples julep will come soon! :-D

[andyferris]

I agree Simon, but note that MVector is already implemented purely in terms of pointers (as in getindex and setindex!). Codegen is worse: approximately half the speed of SVector which is unfortunate. But still quite a lot faster than Vector in many cases!

Apart from the fact that it lacks SIMD and might have an extra pointer indirection, it is possible the codegen is worse still for other silly reasons - I'd like to understand this better. But like I said in many cases, MVector is a lot faster than Vector. The obvious advantage is that if you can avoid a heap allocation you can save a lot of time on allocation and GC, and sometimes you really need a mutable object to implement an efficient algorithm. The benchmarks are enlightening.

The mutable tuple thing should resolve all of this and these 3 types will become 1.

[eschnett]

@andyferris What about SIMDElement? If you suggest that Base.VecElement could be renamed to Base.SIMDElement -- yes, that might be a good idea.

On the other hand, renaming SIMD.Vec to SIMD.SIMDElement is not a good idea, because the SIMD type is a vector, so renaming it to SIMDElement would be confusing.

[andyferris]

Yes I meant Base.VecElement.

[andyferris]

One decent option, could implement ImmutableArrays-style typealias's. Some possibilities

# Option 1, this list is direct from ImmutableArrays.jl
export Vector1,   Vector2,   Vector3,   Vector4,
       Matrix1x1, Matrix1x2, Matrix1x3, Matrix1x4,
       Matrix2x1, Matrix2x2, Matrix2x3, Matrix2x4,
       Matrix3x1, Matrix3x2, Matrix3x3, Matrix3x4,
       Matrix4x1, Matrix4x2, Matrix4x3, Matrix4x4

# Option 2: Some new hybrid FixedSizeArray/ImmutableArray names
typealias Vec3{T} SVector{3,T}
typealias Mat3x3{T} SMatrix{3,3,T,9}
# etc...

# Option 3: Seen this in C++, but I just realized OpenEXR's Imath::V3d is "d" for "double" not "dimensions"
typealias V3d{T} SVector{3,T}

# Option 4, these are probably the correct Imath equivalents in Julia
typealias V3{T} SVector{3,T}
typealias M33{T} SMatrix{3,3,T,9} # or M3x3{T} ? Works beyond dimension 9.

Option 1 can be implemented just like our compatibility layer for FixedSizeArrays, so users type using StaticArrays.ImmutableArrays and they won't need to change old code. But those names aren't as short as they could be. If we want super-short names like V3 we could also make it optional via an extra using StaticArrays.ShortNames.

To be honest, option 4 seems pretty sweet to me.

[andyferris]

@twadleigh I'll ping you since your opinion could be valuable here after authoring ImmutableArrays.

[andyferris]

To be honest, option 4 seems pretty sweet to me.

And option 2 is also quite readable.