enumerate() like equivalents for iterating over columns/rows of a matrix

[AzamatB]

It would be good to be able to iterate over columns (rows) as follows:

for col in columns(A)
    # some code
end

This can be part of a more generic interface slices(A, dims), with rows(A) and columns(A) being alias for slices(A, 1) and slices(A, 2) respectively.

With this we can consider deprecating mapslices(f, A; dims) in favor of map(f, slices(A, dims))

[andreasnoack]

You'll save one line of code compared to

for i in 1:size(M,2)
    col = slice(M,:,i)
    # some code
end

Would there be any other advantages?

[lnsp]

It makes the code clearer and easier to understand. I would prefer it over slice, though I would rather call it columns.

for col in columns(matrix)
    # some code
end

and

for row in rows(matrix)
    # some code
end

[nalimilan]

If anything, I guess there would be a single method taking the index of the dimension, e.g.

for row in eachslice(array, 1)
    # some code
end

[StefanKarpinski]

If slice(M,:,i) were expensive, then this iterator could be implemented more efficiently. Not saying we should do this, but it's a possible argument for this kind of thing.

[AzamatB]

+1 for @mooxmirror's suggestion.
And I agree that the main benefit of implementing these functions is the code that is clearer and easier to understand.

[mauro3]

This is somewhat similar to sparse matrix iteration: http://docs.julialang.org/en/release-0.4/stdlib/arrays/#Base.nzrange. If something like this were to be added, could it be designed to work efficiently for sparse and other fancy matrices too?

[AzamatB]

This also potentially allows compiler to optimize loops to be stride efficient. For example when it sees the following code:

for row in rows(matrix)
    # some code
end

it could transform it to the following

for col in columns(matrix')
    # some code
end

[cortner]

Just to add that I'd also enjoy having something along these lines. I particular like the

for row in rows(matrix)
     #
end

notation

[axsk]

+1
The twoline version suggested by @andreasnoack of course does the job, but in a rather cryptic way given iterating over rows is such a natural operation.

But I am not sure if we should adopt the sub or the slice behaviour, keeping or dropping singleton dimensions respectively. I guess when I iterate over rows(matrix) I would actually expect row vectors, i.e. keeping the singleton dimensions.

I also agree @nalimilan that we should have a general iterator for higher dimensional arrays. Alternatively to eachslice I would call it slices, and furthermore also have subs for keeping the singleton dimension, as natural extensions to slice and sub.

OT: Like @nalimilan I would naturally expect eachslice(m, 1) to return rows, much like slicedim(m, 1, rownumber) also selects a row. But mapslices(f, m, [1]) applies f to columns. On the other hand mapslices(sum, m, [1]) is consistent with sum(m,1), the column-summation, but actually 1 is the dimension index of the rows and 2 of the columns...
Is it just me or is anyone else also confused by these semantics?

[AzamatB]

@axsk +1.
It would be nice to have consistency in dimension convention across the methods you have mentioned.

[Mice7R]

Well rows and columns is clearer of what is doing while slice would be a bit more obscure.
I agree with @nalimilan with having a generic iterator but I think that rows and columns must be present.
@axsk Yeah It confuses me too.

[nalimilan]

Well rows and columns is clearer of what is doing while slice would be a bit more obscure.
I agree with @nalimilan with having a generic iterator but I think that rows and columns must be present.

As long as we don't provide nrow(x) = size(x, 1) and ncol(x) = size(x, 2), we shouldn't offer eachrow(x) = eachslice(x, 1) and eachcol(x) = eachslice(x, 2) either.

[tbreloff]

I'll put in my vote for the following:

If there's interest in this, I can put together a PR for this and a RowIterator, which is similar. Should I define any other methods? What file might this live in?