|
size1 and size2
|
|
Re: size1 and size2
Marco Guazzone schrieb:
> Dear all,
>
> Just for curiosity...
>
> Why does ublas use names such as "size1" and "size2" instead of
> something more intuitive (IMO) like "n_rows" and "n_columns"?
>
>
because of historical design decisions of the original authors. Now we
keep it for compatibility - that's life ;-)
(btw. we could also use size<1>() and size<2>() ...)
mfg
Gunter
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Wed, Sep 9, 2009 at 11:13 PM, Gunter Winkler < guwi17@...> wrote:
> Marco Guazzone schrieb:
>> Dear all,
>>
>> Just for curiosity...
>>
>> Why does ublas use names such as "size1" and "size2" instead of
>> something more intuitive (IMO) like "n_rows" and "n_columns"?
>>
>>
> because of historical design decisions of the original authors. Now we
> keep it for compatibility - that's life ;-)
Ohhh ok! :)
Maybe adding inline methods and free functions with more user-friendly
names like the ones below could be a good idea and does not break
backward-compatibility:
--- [code] ---
// in matrix.hpp
template<...> class matrix:...
{
BOOST_UBLAS_INLINE
size_type n_rows() const { return size1_; }
BOOST_UBLAS_INLINE
size_type n_columns() const { return size2_; }
};
// same for the other types
// in detail/raw.hpp
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(M const& m ) { return m.n_rows(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns( M const& m) { return m.n_columns(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(matrix_reference<M> const& m) { return n_rows(m.expression()); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns(matrix_reference<M> const& m ) { return
n_columns(m.expression()); }
--- [/code] ---
What do you think?
>
> (btw. we could also use size<1>() and size<2>() ...)
Didn't find that function in uBlas. Where is it?
Maybe did you mean: size1(m) and size2(m)?
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Marco Guazzone wrote:
>
> Ohhh ok! :)
>
> Maybe adding inline methods and free functions with more user-friendly
> names like the ones below could be a good idea and does not break
> backward-compatibility:
>
I would vote for col_size and row_size, or column_size and row_size. Having
a "size" in the name is more consistent with STL.
Cheers,
Rutger
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Thu, Sep 10, 2009 at 10:16 AM, Rutger ter Borg < rutger@...> wrote:
> Marco Guazzone wrote:
>
>>
>> Ohhh ok! :)
>>
>> Maybe adding inline methods and free functions with more user-friendly
>> names like the ones below could be a good idea and does not break
>> backward-compatibility:
>>
>
> I would vote for col_size and row_size, or column_size and row_size. Having
> a "size" in the name is more consistent with STL.
>
Good choice, maybe "cols_size" and "rows_size"?
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Thu, Sep 10, 2009 at 12:39 PM, Marco Guazzone
< marco.guazzone@...> wrote:
> On Thu, Sep 10, 2009 at 10:16 AM, Rutger ter Borg < rutger@...> wrote:
>>
>> I would vote for col_size and row_size, or column_size and row_size. Having
>> a "size" in the name is more consistent with STL.
>>
>
> Good choice, maybe "cols_size" and "rows_size"?
>
The same should apply to iterators. Something like:
iterator1 ==> row_iterator
iterator2 ==> column_iterator
reverse_iterator1 ==> reverse_row_iterator
// ...
matrix::begin1() ==> matrix::row_begin()
matrix::begin2() ==> matrix::column_begin()
matrix::find1() ==> matrix::row_find()
// ...
iterator1::index1() ==> row_iterator::row_index()
iterator1::index2() ==> row_iterator::column_index()
// ...
Cheers!
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Hello all,
I suggest to only add new free functions because this can be easily done
in a separate header file like "matix_utils.hpp" and "vector_utils.hpp"
Am Thursday 10 September 2009 schrieb Marco Guazzone:
> On Thu, Sep 10, 2009 at 12:39 PM, Marco Guazzone
>
> < marco.guazzone@...> wrote:
> > On Thu, Sep 10, 2009 at 10:16 AM, Rutger ter Borg
< rutger@...> wrote:
> >> I would vote for col_size and row_size, or column_size and
> >> row_size. Having a "size" in the name is more consistent with STL.
> >
> > Good choice, maybe "cols_size" and "rows_size"?
>
> The same should apply to iterators. Something like:
>
> iterator1 ==> row_iterator
> iterator2 ==> column_iterator
> reverse_iterator1 ==> reverse_row_iterator
I'd try to stay close to MTL4 if possible.
lets summarize the need :
num_rows(MAT); num_cols(MAT); size(VEC);
maybe also: size<tag::row>(MAT); size<tag::column>(MAT)
What do you think about a similar approach for iterators. Sometime one
needs an "major" and "minor" iterator (no matter what the orientation
of the matrix is). Sometimes one needs an explicit row-iterator whose
value type is essentially a reference to a matrix row. (BTW. IMO the
original iterator design of uBLAS is very bad for non-dense matrices.)
maybe we start with:
miter = begin<tag::major>(MAT);
subiter = begin<tag::minor>(miter);
fastiter = begin<tag::nz>(MAT); // iterate over all non-zeros
(see also http://www.osl.iu.edu/research/mtl/mtl4/doc/iteration.html)
Will anyone take the task to provide a set of free functions that simply
call the existing member functions?
mfg
Gunter
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Thu, Sep 10, 2009 at 8:48 PM, Gunter Winkler < guwi17@...> wrote:
> Hello all,
>
> I suggest to only add new free functions because this can be easily done
> in a separate header file like "matix_utils.hpp" and "vector_utils.hpp"
>
Hmmm, but in this way we risk to give an inconsistent interface.
In MTL4 we have both member functions and free functions
>
> I'd try to stay close to MTL4 if possible.
>
> lets summarize the need :
>
> num_rows(MAT); num_cols(MAT); size(VEC);
>
> maybe also: size<tag::row>(MAT); size<tag::column>(MAT)
>
> What do you think about a similar approach for iterators. Sometime one
> needs an "major" and "minor" iterator (no matter what the orientation
> of the matrix is). Sometimes one needs an explicit row-iterator whose
> value type is essentially a reference to a matrix row. (BTW. IMO the
> original iterator design of uBLAS is very bad for non-dense matrices.)
Good idea, this is close both to MTL4 and to GLAS.
For iterators, there are also the find* functions.
It seems there's no equivalent in MTL4
>
> maybe we start with:
>
> miter = begin<tag::major>(MAT);
> subiter = begin<tag::minor>(miter);
>
> fastiter = begin<tag::nz>(MAT); // iterate over all non-zeros
>
> (see also http://www.osl.iu.edu/research/mtl/mtl4/doc/iteration.html)
>
> Will anyone take the task to provide a set of free functions that simply
> call the existing member functions?
>
I have little experience with uBlas and little free time.
But if nobody can take the task I can try... A slow devel is better
than nothing ;)
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Fri, Sep 11, 2009 at 4:08 AM, Marco Guazzone <marco.guazzone@...> wrote:
On Thu, Sep 10, 2009 at 8:48 PM, Gunter Winkler < guwi17@...> wrote:
In MTL4 we have both member functions and free functions
Marco: What have your experiences with MTL4 been? Is it ready to be considered as a matrix library? Do you think it will be the ublas successor eventually?
-Jesse
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Fri, Sep 11, 2009 at 2:15 PM, Jesse Perla < jesseperla@...> wrote:
>
> On Fri, Sep 11, 2009 at 4:08 AM, Marco Guazzone < marco.guazzone@...>
> wrote:
>>
>> On Thu, Sep 10, 2009 at 8:48 PM, Gunter Winkler < guwi17@...> wrote:
>>
>> Hmmm, but in this way we risk to give an inconsistent interface.
>> In MTL4 we have both member functions and free functions
>
> Marco:
> What have your experiences with MTL4 been? Is it ready to be considered as
> a matrix library? Do you think it will be the ublas successor eventually?
>
No experience. :((
Just looked a bit.
For what I saw there're few features with respect to uBlas, such as:
* cursors.
* the use of "parameters" as template argument for matrices (reduce
the number of template arguments)
IMO these feature only does not motivate a transition from uBlas to MTL4.
It does in case MTL4 performances outperform uBlas's ones.
I've also looked a bit to GLAS library.
Maybe we need to take it into consideration as the ublas successor too.
Cheers!
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
> maybe we start with:
>
> miter = begin<tag::major>(MAT);
> subiter = begin<tag::minor>(miter);
Hi All,
Some of the data-structures I use often are vector of vectors.
What would be required (and that I desire) so I can use ublas without
changing my code is to overload the functionality of boost/range.hpp as
follows:
miter = boost::begin(MAT); // calls begin<tag::major>(MAT);
subiter = boost::begin(*miter); // calls begin<tag::minor>(miter);
Does that seem feasible, reasonable?
Thanks for giving it a thought, if your time permits it.
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Some parts of this message have been removed.
Learn more about Nabble's security policy.
It should be just a couple of lines of code to start with. I think Marco has offered to get his fingers on that in a previous post and I believe the developers want this in uBlas pretty soon, as long as a patch is available. Best Nasos > To: ublas@...> From: erwann.rogard@...> Date: Sun, 13 Sep 2009 17:46:33 -0400 > Subject: Re: [ublas] size1 and size2 > > > > maybe we start with: > > > > miter = begin<tag::major>(MAT); > > subiter = begin<tag::minor>(miter); > > Hi All, > > Some of the data-structures I use often are vector of vectors. > > What would be required (and that I desire) so I can use ublas without > changing my code is to overload the functionality of boost/range.hpp as > follows: > > miter = boost::begin(MAT); // calls begin<tag::major>(MAT); > subiter = boost::begin(*miter); // calls begin<tag::minor>(miter); > > Does that seem feasible, reasonable? > > Thanks for giving it a thought, if your time permits it. > > _______________________________________________ > ublas mailing list > ublas@...> http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: nasos_i@...
Hotmail: Powerful Free email with security by Microsoft. Get it now.
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Nasos Iliopoulos wrote:
> It should be just a couple of lines of code to start with. I think Marco
> has offered to get his fingers on that in a previous post and I believe
> the developers want this in uBlas pretty soon, as long as a patch is
> available.
> Best
> Nasos
So I take it specializations such as range_iterator<Mat>::type etc. will
also be avaible. It's all good. Thanks!
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
 Re: size1 and size2
Just want to voice my opinion on this question of size1() vs. n_rows() [or whatever]. I don't really see how "n_rows" or "size_rows" is any more user-friendly than size1. Claiming that they are more descriptive assumes a particular interpretation of the matrix indexes--in particular, that the first index is a "row" index). Though I concede that this interpretation is very common, it certainly seems plausible that some programmers might find themselves in situations where a different interpretation is natural, and the names you suggest would actually be much more confusing than the existing ones.
Isn't it pretty clear that size1 gives the size of the matrix in the first index? If it's not obvious, one simple sentence of explanation in the API documentation quickly clarifies the usage, and any programmer with basic familiarity of STL and aptitude to consider using uBLAS will immediately internalize it. Moreover, size1 is completely general; it makes no assumptions about the interpretation of the matrix data. So, if I had a vote, I would vote to keep size1() and size2().
Thanks for your consideration.
Curtis Gehman Burlingame, CA
Maybe adding inline methods and free functions with more user-friendly
names like the ones below could be a good idea and does not break
backward-compatibility:
--- [code] ---
// in matrix.hpp
template<...> class matrix:...
{
BOOST_UBLAS_INLINE
size_type n_rows() const { return size1_; }
BOOST_UBLAS_INLINE
size_type n_columns() const { return size2_; }
};
// same for the other types
// in detail/raw.hpp
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(M const& m ) { return m.n_rows(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns( M const& m) { return m.n_columns(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(matrix_reference<M> const& m) { return n_rows(m.expression()); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns(matrix_reference<M> const& m ) { return
n_columns(m.expression()); }
--- [/code] ---
What do you think?
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I have a problem with rows and cols like other people have with left and right. I have to think which is which :). Beyond that I prefer size1 and size2 for the same reasons Curtis does, but i don't see much of a problem providing overloads to them under the umbrella of a utils.h header or something. size<1> and size<2> would be my personal favourite (as Gunter proposed), but I think it goes too much for the average user. Best Nasos
From: csgehman@...To: ublas@...Date: Sun, 13 Sep 2009 17:16:21 -0700 Subject: Re: [ublas] size1 and size2 Just want to voice my opinion on this question of size1() vs. n_rows() [or whatever]. I don't really see how "n_rows" or "size_rows" is any more user-friendly than size1. Claiming that they are more descriptive assumes a particular interpretation of the matrix indexes--in particular, that the first index is a "row" index). Though I concede that this interpretation is very common, it certainly seems plausible that some programmers might find themselves in situations where a different interpretation is natural, and the names you suggest would actually be much more confusing than the existing ones.
Isn't it pretty clear that size1 gives the size of the matrix in the first index? If it's not obvious, one simple sentence of explanation in the API documentation quickly clarifies the usage, and any programmer with basic familiarity of STL and aptitude to consider using uBLAS will immediately internalize it. Moreover, size1 is completely general; it makes no assumptions about the interpretation of the matrix data. So, if I had a vote, I would vote to keep size1() and size2().
Thanks for your consideration.
Curtis Gehman Burlingame, CA
Maybe adding inline methods and free functions with more user-friendly
names like the ones below could be a good idea and does not break
backward-compatibility:
--- [code] ---
// in matrix.hpp
template<...> class matrix:...
{
BOOST_UBLAS_INLINE
size_type n_rows() const { return size1_; }
BOOST_UBLAS_INLINE
size_type n_columns() const { return size2_; }
};
// same for the other types
// in detail/raw.hpp
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(M const& m ) { return m.n_rows(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns( M const& m) { return m.n_columns(); }
template <typename M>
BOOST_UBLAS_INLINE
int n_rows(matrix_reference<M> const& m) { return n_rows(m.expression()); }
template <typename M>
BOOST_UBLAS_INLINE
int n_columns(matrix_reference<M> const& m ) { return
n_columns(m.expression()); }
--- [/code] ---
What do you think?
Bing brings you health info from trusted sources. Try it now!
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Nasos Iliopoulos wrote:
> I have a problem with rows and cols like other people have with left and
> right. I have to think which is which :).
> Beyond that I prefer size1 and size2 for the same reasons Curtis does,
> but i don't see much of a problem providing overloads to them under the
> umbrella of a utils.h header or something.
> size<1> and size<2> would be my personal favourite (as Gunter proposed),
> but I think it goes too much for the average user.
>
> Best
> Nasos
>
size_major would be closer to the STL convention, and avoids a new
convention (row) on top of another (major). However size1, size<1>, or
perhaps size<0> all seem fine.
Note, though, that I don't use ublas that much (for now).
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Mon, Sep 14, 2009 at 4:23 AM, er < erwann.rogard@...> wrote:
> Nasos Iliopoulos wrote:
>>
>> I have a problem with rows and cols like other people have with left and
>> right. I have to think which is which :).
>> Beyond that I prefer size1 and size2 for the same reasons Curtis does,
>> but i don't see much of a problem providing overloads to them under the
>> umbrella of a utils.h header or something.
>> size<1> and size<2> would be my personal favourite (as Gunter proposed),
>> but I think it goes too much for the average user.
>>
>> Best
>> Nasos
>>
>
> size_major would be closer to the STL convention, and avoids a new
> convention (row) on top of another (major). However size1, size<1>, or
> perhaps size<0> all seem fine.
>
Hello!
I think it would be necessary to distinguish between the matrix
theoretical concept from implementation detail.
I'm not a mathematician so correct me if I'm wrong.
For what I know a matrix is defined in terms of rows and columns; for instance:
* From http://en.wikipedia.org/wiki/Matrix_%28mathematics%29 "A matrix with m rows and n columns is called an m-by-n matrix or m
× n matrix, while m and n are called its dimensions"
* From http://mathworld.wolfram.com/Matrix.html "An mXn matrix consists of m rows and n columns, and the set of mXn
matrices with real coefficients is sometimes denoted R^(mXn)"
What is argued in the previous emails is about matrix orientation that
IMO is an implementation detail.
So, if I declare a ublas::matrix(m,n) what I expect is that this
matrix has m rows and n columns regardless its orientation
Note, this is what I expect. Maybe it is not the phylosophy under the uBlas lib.
Let me know in this case and I'll stop to stress ;))
Anyway, maybe we can keep the two concept separate. So for a matrix A(m,n):
A.num_rows() ==> m
A.num_cols() ==> n
A.size1() ==> m if row_major OR n if column_major
A.size2() ==> n if row_major OR m if column_major
At least this is how the choice made by MTL4 (actually it uses dim1
and dim2 in place of size1 and size2, respectively).
What do you think?
Cheers,
-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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. Best Nasos > Date: Mon, 14 Sep 2009 09:47:49 +0200 > From: marco.guazzone@...> To: ublas@...> Subject: Re: [ublas] size1 and size2 > > On Mon, Sep 14, 2009 at 4:23 AM, er < erwann.rogard@...> wrote: > > Nasos Iliopoulos wrote: > >> > >> I have a problem with rows and cols like other people have with left and > >> right. I have to think which is which :). > >> Beyond that I prefer size1 and size2 for the same reasons Curtis does, > >> but i don't see much of a problem providing overloads to them under the > >> umbrella of a utils.h header or something. > >> size<1> and size<2> would be my personal favourite (as Gunter proposed), > >> but I think it goes too much for the average user. > >> > >> Best > >> Nasos > >> > > > > size_major would be closer to the STL convention, and avoids a new > > convention (row) on top of another (major). However size1, size<1>, or > > perhaps size<0> all seem fine. > > > > Hello! > > I think it would be necessary to distinguish between the matrix > theoretical concept from implementation detail. > I'm not a mathematician so correct me if I'm wrong. > For what I know a matrix is defined in terms of rows and columns; for instance: > * From http://en.wikipedia.org/wiki/Matrix_%28mathematics%29 > "A matrix with m rows and n columns is called an m-by-n matrix or m > × n matrix, while m and n are called its dimensions" > > * From http://mathworld.wolfram.com/Matrix.html > "An mXn matrix consists of m rows and n columns, and the set of mXn > matrices with real coefficients is sometimes denoted R^(mXn)" > > What is argued in the previous emails is about matrix orientation that > IMO is an implementation detail. > So, if I declare a ublas::matrix(m,n) what I expect is that this > matrix has m rows and n columns regardless its orientation > > Note, this is what I expect. Maybe it is not the phylosophy under the uBlas lib. > Let me know in this case and I'll stop to stress ;)) > > Anyway, maybe we can keep the two concept separate. So for a matrix A(m,n): > A.num_rows() ==> m > A.num_cols() ==> n > A.size1() ==> m if row_major OR n if column_major > A.size2() ==> n if row_major OR m if column_major > At least this is how the choice made by MTL4 (actually it uses dim1 > and dim2 in place of size1 and size2, respectively). > > What do you think? > > > Cheers, > > -- Marco > _______________________________________________ > ublas mailing list > ublas@...> http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: nasos_i@...
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
Curtis Gehman wrote:
[snip]
> Moreover, size1 is
> completely general; it makes no assumptions about the interpretation
> of the matrix data.
[snip]
IMHO, the addition of interpretation is the whole point of a linear algebra
library. Without this meaning, it's just a block of data, and, IMHO,
attaching the name "matrix" to it doesn't make sense. E.g., multi_array
boost::multi_array< double, 2 > m_data;
or "2d_valarray" would much better fit the description for something that
provides "size1" and "size2". Without interpretations in the context of
linear algebra, we might as well allow
A = op1( b, op2( c ) );
and refer users to the manual :-).
Cheers,
Rutger
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
|
Re: size1 and size2
On Mon, Sep 14, 2009 at 8:58 AM, Nasos Iliopoulos <nasos_i@...> 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:
- Tensors have an order of dimensions. Consider the sizes of the matrix to be those dimensions in order for the 2nd order tensor.
- So size1(), size2() make sense with this interpretation.
- I don't see the problem with having an overload of "num_rows" and "num_columns" that forwards to size1 and size2 respectively, which I think is the GLAS interface. I also get messed up with rows vs. columns, but some people find this more intutive. I think that calling it "rows" and "columns" is a bad idea since it could conceptually be messed up with an interface that returns a row or column.... or future rows, columns interface that return a range of them.
- Consider adding in size<1>(), size<2>(), which might be more consistent with higher order linear algebra. However, multi_array works by giving access to a container of its extents, so this interface wouldn't be consistent.... In that case, having an interface called "shape" that returns a vector of size_t is likely the most compatible (I believe it is how Blitz++ and multi_array work). Also, people are going to get messed up with size<0>() vs. size<1>() here since they may view it as a list of extents starting at 0, the normal way to count when you are allowed to pass in an index.
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
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: lists@...
|
signature.asc (204 bytes) 