On Mon, Sep 14, 2009 at 8:58 AM, Nasos Iliopoulos <nasos_i@hotmail.com> wrote:
Hello,

> A.size1() ==> m if row_major OR n if column_major
> A.size2() ==> n if row_major OR m if column_major
I think this tries to bring together STL semantics and Mathematical semantics and should be avoided. I argue that it should be: size1()<=>nrows and size2()<=>ncols. After all an implementation like  begin<tag::major>(MAT); can provide more elegant STL semantics if someone wants to use it.
If you think that it is useful to have a major and minor size_..() member function I believe the one proposed by er is more apropriate, i.e. size_major, size_minor.
For the record basic_column_major and  basic_row_major functors already implement this functionality (members size_M and size_m) in functional.hpp. This implementation is a bit odd at first but it is there to avoid exposing matrix into layout_type.

My preference would be for whatever is consistent with GLAS and/or MTL.  I want to write generic code that could work with different libraries in case I switch up.  We also might want to check up with eigen.

However, I think that switching the meaning of size1 depending on storage ordering is a bad idea.  You want to write generic code that works for any type of matrix expression, and not have to check storage ordering each time.  And fortran vs. C storage ordering doesn't even apply to all matrix types.

Last, I would love us to have something that makes conceptual sense for higher order tensors as well.  I write a lot of code that works with data structures of different dimensions, and find dealing with different extent sizes to be difficult.  So I am sympathetic to:
So to summarize my recommendation:
size1() == num_rows()
size2() == num_columns()

shape() gives array of the extents in a Container.  Similar interface to matlab, blitz++, multi_array.

-Jesse