RFC: Make strides into a generic trait

[andyferris]

My take on a pathway for replacing StridedArray with a more generic and extensible trait. This simply makes the strides function a bit more generic, but does not rearrange any of the dispatch patterns around StridedArray or anything like that.

Returns nothing for non-strided arrays, otherwise gives the strides in memory. Useful as an extensible trait in generic contexts and for arranging dispatch patterns, and simpler to overload for cases of "wrapped" arrays where "stridedness" can be deferred to the parent rather than a complex (and inextensible) method signature.

Thoughts welcome. Functions on instances seem to be the current trend in trait patterns (in part because the answers of interest may not be available from type information alone - in this context take a::Transpose{Float64, AbstractMatrix} (note the lack of a <:), where we can't know if the parent array type is strided or not until we query parent(a)). I'm not sure how I feel about nothing as a sentinel value here, or the generic overload of stride.

Fixes #29705. Closes #29135 and closes #30429. Touches on JuliaLang/LinearAlgebra.jl#186, #10064, #10889, maybe more. CC @mbauman @timholy @raghav9-97

• Needs tests

[timholy]

Using nothing as the default here is interesting. On balance I think this is a good way to go.

[timholy]

More compact, if desired:

return str === nothing ? nothing : str[k]

[mcabbott]

The existing function allows k>ndims(A), like stride([1,2,3], 99) == 3.

[mauro3]

Use A and strides(parent(A))?

[mbauman]

Clever, clever, clever. So instead of having a separate trait hierarchy of storage types, we just pass strides itself as a value. I like it. Now my question is — what is a strides at its heart? Is it at all possible to use values (instead of traits) to encapsulate the rigorous demands of @dlfivefifty's storage system from #25558?

In other words, this makes me think that strides is really a function that takes an index as input and outputs a storage location. Thus, in contrast to #25558, you don't look at the Base.MemoryLayout to see if you can call strides; instead, you simply ask it for the function that computes a memory location for you. We'd of course want to use first-class callable structs such that you can dispatch directly on the StridedLocationFunction and access its tuple for calling into BLAS. And then we could eventually implement a SparseCSCLocationFunction or BandedLocation or whatever.

Now, I don't think a function from index -> storage is the right concept here… what is the right concept? Is there one? Am I going off the deep end?

[dlfivefifty]

There were two conflating uses of MemoryLayout in #25558: looking up data, and dispatching on mul!. I like @mbauman's idea for the looking up data part. But I don't see how it helps with mul!, where we need to handle different permutations of strided, banded, triangular, etc.

[andyferris]

Nice idea, Matt. That’s some next level stuff!

@dlfivefifty I think the point is that there would be functions of different types returned by strides. These would be different types of structs containing the strides etc and with a call (or getindex?) overload. It would be designed so you can dispatch on the type of this mapping for thing like mul!.

[dlfivefifty]

I get that. I just don't see how it would work in dispatch with composed layouts like Symmetric(UpperTriangular(...)). Unless the proposal is essentially 1-to-1 with the layouts in #25558, just with an added call override.

But conflating memory layout with mul! behaviour was never a good design anyways. Maybe something like the following would work.

1. Use your proposal for strides
2. Make a lazy Applied{Style<:ApplyStyle} that mimics Broadcasted{Style<:BroadcastStyle} for lazy function application
3. Have a default:

struct StridedApplyStyle{F<:Function, ST<:Tuple} <: ApplyStyle
    f::F
    strides::ST
end

ApplyStyle(::typeof(*), A::AbstractArray...) = StridedApplyStyle(*, strides.(A))

as the type that determines the apply style from the strides.

[andyferris]

Right - we’ll definitely need a “promotion” mechanism to control dispatch of operations on multiple containers.

[Jutho]

+1

[oxinabox]

What is the status on this?

[mbauman]

Just a note that our potential design space just got significantly larger with #34126 — we no longer need to be fearful of holding onto arrays in structs.

[oscardssmith]

Triage likes this. How much work is needed to merge?

[andyferris]

I have rebased this and update stride to accept larger dimensions as currently supported.

How much work is needed to merge?

It's been such a long time and I haven't been following the changes closely - does anyone else know if more should be done?

[nhz2]

Closing this based on the triage decision in #61807 to go with a more trait like solution. I am working on this in #60964