Proposal: variadic mapslices

[iamed2]

There has been some discussion about variadic and dyadic mapslices, such as in #5140 and issues linked therein, as well as on the Julia Slack starting here.

Approaches specifying dims for both arrays have so far been unsuccessful. However, given the abundant functionality for transforming array shapes, I believe a mapslices which only specified one set of dims for all arrays could still be useful.

I propose:

Phase 1 (pre-1.0)

1. Implement mapslices(f, dims::Tuple, As::A...) where {N,A<:(AbstractArray{T,N} where T)} which returns a single array
2. Deprecate mapslices(f, A::AbstractArray, dims::Tuple) to mapslices(f, dims, A)

Phase 2 (optionally post-1.0)

1. Implement an eachslice(A, dims) IteratorsMD function
2. Reimplement mapslices in terms of eachslice

Unless there are serious concerns I can implement a PR for phase 1.

[ararslan]

My only problem with this is the argument order; typically the dimensions come after the array. This would make mapslices kind of a weird special case in that regard.

[iamed2]

Does Julia have any other variadic functions which take dimensions? I think passing in a tuple of arrays would be worse but that's the only alternative I can think of, short of a monstrous generated function.

[tkelman]

or kwargs for dimensions, which I think a few people would like us to move towards more generally if keyword performance can be fixed soon

[iamed2]

That would prevent e.g. AxisArrays from dispatching on the type of dims.

[StefanKarpinski]

Currently. Keywords based on NamedTuples might fix that though. cc @JeffBezanson – is that a possibility?

[timholy]

We may be closing in on a fast inferrable variant of mapslices that we can post. Struggling a bit with the dimension API, though; my current favorite is to replace dims = [1,3] with dims = (:, *, :) (for a 3d array). The point being that * means "substitute me with an integer" and : means "this is where a colon goes."

CC @Cody-G

[timholy]

There's a package JuliennedArrays which is clever both in its naming and design. It provides arbitrary slice iterators and also turns mapslices into map(f, sliceiterator). The biggest negative of the design is that it doesn't shield the parent array from side effects of f.

Cross-reference #14491.