`stride`/`strides` signature too broad?

[timholy]

The docstring for stride:

help?> stride
search: stride strides StridedArray StridedVector StridedMatrix StridedVecOrMat strwidth SymTridiagonal

  stride(A, k)

  Returns the distance in memory (in number of elements) between adjacent elements in dimension k.

specifies "in memory", but the signature for stride is stride(a::AbstractArray, i::Integer), and some AbstractArrays do not even store their values in memory:

julia> stride(1:5, 1)
1

julia> isa(1:5, StridedArray)
false

Should we change it to StridedArray? The biggest problem with this is that StridedArray was the motivating poster child for the desirability of traits, because StridedArray cannot be extended to user types.

We could introduce an IsStrided trait,

strided(A::StridedArray) = IsStrided()
strided(A) = NotStrided()

and dispatch on it for strides and stride. But then that implicitly places some expectation that the linear algebra code might switch to the trait rather than dispatching on StridedArray, and that's a lot of code to modify. So I didn't want to do this lightly.

[stevengj]

The stride implementation assumes column-major, so it seems like it should be specific to Array, not StridedArray. According to the manual, new DenseArray subtypes are supposed to provide their own stride implementations anyway.

[dlfivefifty]

I'm working on resolving this issue (in conjunction with #25247) but there seems to be confusion on what stride is suppose to mean.

I take it this comment

https://github.com/JuliaLang/julia/blob/master/base/subarray.jl#L254

is wrong? And the code below involving substride should be re-written to call the parents stride?

[timholy]

Yes, the two notions (is it memory layout or is it essentially accumulate(*, size(A))?) are the main trouble here. I would be guided by the docstring, which specifies that the true meaning is memory layout.

In this case, though, I think the comment is referring to the fact that in

julia> A = [1 4; 2 5; 3 6]
3×2 Array{Int64,2}:
 1  4
 2  5
 3  6

julia> v = view(A, 1:2, :)
2×2 view(::Array{Int64,2}, 1:2, :) with eltype Int64:
 1  4
 2  5

v still has valid strides even though it doesn't have linear memory arrangement (in the sense that v[1, 2] is not the next location in memory after v[2, 1]).

As you suggest, perhaps the best rewrite would be in terms of calling stride on the parent.

[dlfivefifty]

OK, I've done that in https://github.com/dlfivefifty/julia/tree/dl/stridedarrayinterface and just need to fix some lingering abuses in sparsevector.jl.