Hi, what returns operator[] applied to a matrix object?
It's a great pity it doesn't return a column of the matrix,
like

MatrixXi A(2,3);
cout << A[1];

"should" return the second column A(:,1) in matlab notation.

It seems to return A(1,0) - why?

Thanks for enlightening me,
Helmut.

well,

operator[](i) returns the i-th coefficient of a vector or a matrix once it has been (virtually) transformed into a 1D array.

also if operator[] was reserved for vectors:
1) I don't see why it should return a column and not a row ?
2) it would be weird to have a different behavior for matrix and vector since a vector is nothing else than a special matrix.


benoit: perhaps operator[] should be reserved for vector only, if someone want this behavior he can still use coeff(int) ??

ggael wrote:well,

operator[](i) returns the i-th coefficient of a vector or a matrix once it has been (virtually) transformed into a 1D array.

also if operator[] was reserved for vectors:
1) I don't see why it should return a column and not a row ?
OK, one could argue it should return a column for a column-oriented matrix
but a row for a row-oriented matrix.

It's just that one often has to read and write to a column of a matrix.

2) it would be weird to have a different behavior for matrix and vector since a vector is nothing else than a special matrix.

But to me , IHMO, it's even more weird that a matrix is treated as the
concatenation of its column vectors. I've used this notation in my own
matrix library and it makes code well readable when there are lots of
accesses to columns of matrices.


benoit: perhaps operator[] should be reserved for vector only, if someone want this behavior he can still use coeff(int) ??

No, since operator[] does accept only a single argument (=index) it's ideal
to define it for matrices differently, IHMO.

ggael wrote:benoit: perhaps operator[] should be reserved for vector only, if someone want this behavior he can still use coeff(int) ??

I agree with that change. Indeed operator[] for a matrix is perhaps a bit confusing. Also I don't really expect anybody (I care for) to rely on it so we can do this dirty little API break discretely

I understand your opinion because before Eigen, I also used operator[] to return the column of a matrix, but now I changed radically my mind:

"a.col(i)" is short, clear and self containing. You don't have to know what is the storage order of "a", if "a" is a matrix or a vector, etc. Currently, when you have "a[i]", it is clear too: "a" is a vector, and we get a scalar.

Allowing a[i] to return a column if "a" is a matrix would only add confusion and lead to hard to find bugs. And again, why should it return a column rather than a row? If you change this behavior according to the storage order then it's even worse because you cannot change the storage order without breaking all your code, etc.

HWJ wrote:

ggael wrote:well,

operator[](i) returns the i-th coefficient of a vector or a matrix once it has been (virtually) transformed into a 1D array.

also if operator[] was reserved for vectors:
1) I don't see why it should return a column and not a row ?
OK, one could argue it should return a column for a column-oriented matrix
but a row for a row-oriented matrix.

It's just that one often has to read and write to a column of a matrix.

2) it would be weird to have a different behavior for matrix and vector since a vector is nothing else than a special matrix.

But to me , IHMO, it's even more weird that a matrix is treated as the
concatenation of its column vectors. I've used this notation in my own
matrix library and it makes code well readable when there are lots of
accesses to columns of matrices.


benoit: perhaps operator[] should be reserved for vector only, if someone want this behavior he can still use coeff(int) ??

No, since operator[] does accept only a single argument (=index) it's ideal
to define it for matrices differently, IHMO.

I don't know why you have choosen this convention, stacking columns (and not rows), but it is a blessing because:
treating a matrix as a vector is a very common operation in matrix differential calculus.
This operator is called the vec operator and it does exactly that: stacking columns into a 1-D array.

You can find more information in the matrixCookBook (http://matrixcookbook.com/)
document or in the book of Magnus and Neudecker
@book{Magnus1999_Matrix_differential_calculus_with_applications_in_statistics_and_econometrics,
author = {Jan R. Magnus and Heinz Neudecker},
edition = {2nd},
keywords = {econometrics, economics, matrix_calculus, matrix_theory, statistics},
publisher = {John Wiley & Sons},
title = {Matrix differential calculus with applications in statistics and econometrics},
year = {1999}
}

So it is very natural to have such an operator and as operator[](...) should be reserved to 1-D vectors and operator()(...) for matrices, it was the good thing to do in my opinion.
The thing that I would like to know is why have you choosen the good convention ?
From a C programming point of view, the other is more natural...

- sincerely

Manu

myguel: thanks for your input. just fyi, while column-major storage is the default, you can also choose row-major (even per-matrix). One of the reasons why we chose column major as the default, was that that's what OpenGL uses, and that represents perhaps the most common interoperability case for Eigen.

ggael: what myguel says shows there are really people who rely on operator[] for matrices, so after all i'd say lets keep it and lets just document it. Plus, I wasnt really comfortable with even a small API break in a supposedly stable part...