Suggestion: kick mapslices out of abstractarray.jl

[StephenVavasis]

The function mapslices defined in abstractarray.jl is really complicated. In fact, it is so complicated that I wouldn't be able to maintain it, and I suspect that there are only a few core developers who would be able to. The reason it is so complicated is that it tries to anticipate various use-cases that will arise in subtypes of AbstractArray, which I think is a practice generally discouraged in languages with type hierarchies.

Besides its inherent un-maintainability, another reason to drop it is that the definition of mapslices as a fallback makes certain sparse matrix methods silently fall back to dense matrix methods, but not others. For example, mapslices(sum,speye(1_000_000),1) is fast but median(speye(1_000_000),1) takes forever, as does mapslices(sum,speye(1_000_000),2). Of course, a fast median routine for sparse matrices does not currently exist in the language and would have to be written, but I think that forcing the user to write it (or to explicitly convert his/her sparse matrix to a dense matrix) is preferable to falling back to a slow method, especially since the fall-back is inconsistent.

So I propose that mapslices be dropped from abstractarray.jl and instead rewritten separately for a few subtypes.

[timholy]

@bramtayl has a very nicely written mapslices equivalent in JuliennedArrays. (It does some other cool stuff, too.) When I get a few moments to breathe I'm hoping to help migrate it to Base.

But we can consider the sparse case when we do. Use of view might help (you only need to create a specialized implementation of median(::SubArray{SparseMatrixCSC}) then), but I am concerned about the implications of side effects in the function. Like I said, I haven't had time to check in to @bramtayl's latest thoughts, there may be good solutions already.

[bramtayl]

No haven't thought about spare arrays at all. Definitely an important thing to consider during any future overhaul.

[KristofferC]

I guess not.