PermutedDimsArray

[mcabbott]

Does this package plan to support higher-dimensional arrays? And if so, what should the behaviour be on PermutedDimsArray? Right now:

julia> MemoryLayout(ones(10,20,30)  |> typeof)
DenseColumnMajor()

julia> MemoryLayout(PermutedDimsArray(ones(10,20,30), (1,3,2))  |> typeof)
UnknownLayout()

My context for this is JuliaGPU/CuArrays.jl#664, where these two layouts are equally good for gemm_strided_batched. But the supertypes of DenseColumnMajor all fall under AbstractIncreasingStrides, while the permuted one has strides (1, 200, 10).

[dlfivefifty]

Shouldn’t it just be a StridedLayout() since it’s still a strides array?

[mcabbott]

Yes that's not wrong, it's just that it wouldn't capture the difference between the above and PermutedDimsArray(ones(10,20,30), (3,1,2)), which is (for this purpose) effectively row-major.

I don't know whether such distinctions are common enough to be worth building in here. One could have things like DenseFirstStrided <: StridedLayout, and then the easy case for my function is Union{DenseFirstStrided, DenseColumnMajor}. (Without touching the existing type tree, I think.)

[dlfivefifty]

Ah it’s There and called ColumnMajor() . Though can you determine this at compile time?

[mcabbott]

But ColumnMajor <: ArrayLayouts.AbstractIncreasingStrides, which isn't true here.

And yes, the permutation is part of the type of the PermutedDimsArray.

[dlfivefifty]

Does this need to be at compile time? It seems like you could just dispatch on AbstractStridedLayout and test the strides at run time

[mcabbott]

Yes that's what my PR does right now, and it does work, but seems a little ugly. (It recursively calls itself & tries to re-arrange strides, and if it can't eventually gives up & calls a fallback function.)

[dlfivefifty]

Ok, adding DenseFirstStrided makes sense if it keeps the code clean