Boost logo

Ublas :

Subject: Re: [ublas] size1 and size2
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2009-09-13 20:59:31


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_at_[hidden]
To: ublas_at_[hidden]
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 GehmanBurlingame, CA
At Thu, 10 Sep 2009 09:51:03 +0200, Marco Guazzone <marco.guazzone_at_[hidden]> wrote ...
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.
http://www.bing.com/search?q=pet+allergy&form=MHEINA&publ=WLHMTAG&crea=TXT_MHEINA_Health_Health_PetAllergy_1x1