# Matrix with vector interface.

26 messages
12
Open this post in threaded view
|

## Matrix with vector interface.

 Dear all, My name is Joaquim Duran. I'm new to this mail list. I'm using ublas for signal processing and I'm interested that the matrix have a similar interface to a vector, using a proxy, to apply algorithms designed for vectors. To get an idea, if the element of a vector is a double, then the element of a row facade is a column. If this possible to get this behavior using existing proxies? I'll detail which is the expected behavior of the proxy: Matrix      Column Proxy --------       -------------------- begin2()    begin() end2()       end() rbegin2()   rbegin() rend2()      rend() size2()      size() resize2()   resize() *iter: double  matrix_row(matrix, i) Matrix      Row Proxy --------       -------------------- begin1()    begin() end1()       end() rbegin1()   rbegin() rend1()      rend() size1()      size() resize1()   resize() *iter: double  matrix_column(matrix, i) Example: Sort the columns of a matrix based on their module: using namespace boost::numeric::ublas; template bool less_module(const Vector& v1, const Vector& v2) {      return } main() {      vector v1; } _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Sorry to send the example unfinished. Here it is completed. Example: Sort the columns of a matrix based on their module: using namespace boost::numeric::ublas; template bool less_module(const Vector& v1, const Vector& v2) {       return norm_2(v1) < norm_2(v2); } main() {       matrix m;       column_facade(m);       std::sort(m.begin(), m.end(), less_module); } Joaquim Duran _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 The easisest way, which dos not require a poxy would be to use boost.range and implement a suitable begin(m) and end(m) along with the required iterator and typedefs. than your example would look like: main() {        matrix m;        std::sort(begin(m), end(m), less_module); } On 2012-09-17 11:11, Joaquim Duran wrote: > Sorry to send the example unfinished. Here it is completed. > > Example: Sort the columns of a matrix based on their module: > > using namespace boost::numeric::ublas; > > template > bool less_module(const Vector& v1, const Vector& v2) > { >       return norm_2(v1) < norm_2(v2); > } > > main() > { >       matrix m; >       column_facade(m); >       std::sort(m.begin(), m.end(), less_module); > } > > Joaquim Duran > _______________________________________________ > ublas mailing list > [hidden email] > http://lists.boost.org/mailman/listinfo.cgi/ublas> Sent to: [hidden email] _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Joaquim Duran Hello, Am Monday 17 September 2012 schrieb Joaquim Duran: > Dear all, > > My name is Joaquim Duran. I'm new to this mail list. > > I'm using ublas for signal processing and I'm interested that the > matrix have a similar interface to a vector, using a proxy, to apply > algorithms designed for vectors. To get an idea, if the element of a > vector is a double, then the element of a row facade is a column. If > this possible to get this behavior using existing proxies? Why not using a set of vectors and a matrix view of them? ublas::generalized_vector_of_vector<   double,   ublas::column_major,   ublas::vector > > gvov; this class has a data() function which returns a reference to the storage array (which is a vector >) So you could use gvov.data().begin() as an iterator of vectors. see http://www.boost.org/doc/libs/1_51_0/libs/numeric/ublas/doc/html/classboost_1_1numeric_1_1ublas_1_1generalized__vector__of__vector.html(Additionally you get a very fast swap() of column references compared to swapping all the elements) Alternatively you could sort the indices of the columns instead of the real columns and use the ublas::matrix_indirect view for further computations. see http://www.boost.org/doc/libs/1_51_0/libs/numeric/ublas/doc/html/classboost_1_1numeric_1_1ublas_1_1matrix__indirect.html#_detailsmfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email] signature.asc (205 bytes) Download Attachment
Open this post in threaded view
|

## Re: Matrix with vector interface.

 2012/9/17 Gunter Winkler <[hidden email]>: > Hello, > > Am Monday 17 September 2012 schrieb Joaquim Duran: >> Dear all, >> >> My name is Joaquim Duran. I'm new to this mail list. >> >> I'm using ublas for signal processing and I'm interested that the >> matrix have a similar interface to a vector, using a proxy, to apply >> algorithms designed for vectors. To get an idea, if the element of a >> vector is a double, then the element of a row facade is a column. If >> this possible to get this behavior using existing proxies? > > Why not using a set of vectors and a matrix view of them? > > ublas::generalized_vector_of_vector< >   double, >   ublas::column_major, >   ublas::vector > > gvov; > > this class has a data() function which returns a reference to the > storage array (which is a vector >) > > So you could use gvov.data().begin() as an iterator of vectors. > > see > http://www.boost.org/doc/libs/1_51_0/libs/numeric/ublas/doc/html/classboost_1_1numeric_1_1ublas_1_1generalized__vector__of__vector.html> > (Additionally you get a very fast swap() of column references compared > to swapping all the elements) > > Alternatively you could sort the indices of the columns instead of the > real columns and use the ublas::matrix_indirect view for further > computations. > > see > http://www.boost.org/doc/libs/1_51_0/libs/numeric/ublas/doc/html/classboost_1_1numeric_1_1ublas_1_1matrix__indirect.html#_details> > > mfg > Gunter > The real application is not about sorting columns of a matrix (that was only an illustrative of my purposes). I'm developing classes to represent signals (think in DSP, AD conversor,...) and implement operations to filter data, down-sampling and related operations. Currently all classes are implemented based on bounded_vector (to represent a signal or a sample of a set of signals) and bounded_matrix (to represent a set of signals with the same number of samples for each signal). The advantage of bounded containers is that the resize operations (add or remove signals or samples) don't generate new delete/operations. To filter each signal from a matrix, using a matrix_row or a bounded_vector there is no difference, as each signal must be filtered individually. The facade that I was requesting was to implement the down-sample operation, where each signal can be downloaded individually or all at once in a group of signals, where it is little more efficient. So this is the reason of the request: let a matrix to be viewed as a vector of columns, or a vector of rows, to implement generic algorithms. Joaquim Duran _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Oswin Krause Thanks for your suggestion, but I should implement other operations like size and resize. Joaquim Duran 2012/9/17 Oswin Krause <[hidden email]>: > The easisest way, which dos not require a poxy would be to use boost.range > and implement a suitable > > begin(m) and end(m) along with the required iterator and typedefs. > > than your example would look like: > > main() > { >       matrix m; >       std::sort(begin(m), end(m), less_module); > > } > > On 2012-09-17 11:11, Joaquim Duran wrote: >> >> Sorry to send the example unfinished. Here it is completed. >> >> Example: Sort the columns of a matrix based on their module: >> >> using namespace boost::numeric::ublas; >> >> template >> bool less_module(const Vector& v1, const Vector& v2) >> { >>       return norm_2(v1) < norm_2(v2); >> } >> >> main() >> { >>       matrix m; >>       column_facade(m); >>       std::sort(m.begin(), m.end(), less_module); >> } >> >> Joaquim Duran >> _______________________________________________ >> ublas mailing list >> [hidden email] >> http://lists.boost.org/mailman/listinfo.cgi/ublas>> Sent to: [hidden email] > > > _______________________________________________ > ublas mailing list > [hidden email] > http://lists.boost.org/mailman/listinfo.cgi/ublas> Sent to: [hidden email] _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 boost range gives you automatically size(m). resize is a strange operation for matrices in this context aside from m.resize(rows,columns) which is already there. as long as you add both informations it is fine, but for example in this case it is not clear what should happen: m.resize(0) //no columns-> empty matrix m.resize(10) //10 columns, but how many rows? also a resize of a matrix row doesn't make sense, since all rows need the same size and so on...i went through the same problems (and actually implemented my suggested alternative) and there is no good way for a resize which doesn't lead to all kinds of strange problems. Oswin Krause On 2012-09-18 10:16, Joaquim Duran wrote: > Thanks for your suggestion, but I should implement other operations > like size and resize. > > Joaquim Duran > > > 2012/9/17 Oswin Krause <[hidden email]>: >> The easisest way, which dos not require a poxy would be to use >> boost.range >> and implement a suitable >> >> begin(m) and end(m) along with the required iterator and typedefs. >> >> than your example would look like: >> >> main() >> { >>       matrix m; >>       std::sort(begin(m), end(m), less_module); >> >> } >> >> On 2012-09-17 11:11, Joaquim Duran wrote: >>> >>> Sorry to send the example unfinished. Here it is completed. >>> >>> Example: Sort the columns of a matrix based on their module: >>> >>> using namespace boost::numeric::ublas; >>> >>> template >>> bool less_module(const Vector& v1, const Vector& v2) >>> { >>>       return norm_2(v1) < norm_2(v2); >>> } >>> >>> main() >>> { >>>       matrix m; >>>       column_facade(m); >>>       std::sort(m.begin(), m.end(), less_module); >>> } >>> >>> Joaquim Duran >>> _______________________________________________ >>> ublas mailing list >>> [hidden email] >>> http://lists.boost.org/mailman/listinfo.cgi/ublas>>> Sent to: [hidden email] >> >> >> _______________________________________________ >> ublas mailing list >> [hidden email] >> http://lists.boost.org/mailman/listinfo.cgi/ublas>> Sent to: [hidden email] > _______________________________________________ > ublas mailing list > [hidden email] > http://lists.boost.org/mailman/listinfo.cgi/ublas> Sent to: [hidden email] _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 I'll take a to boost::range. > also a resize of a matrix row doesn't make sense, since all rows need the > same size and so on...i went through the same problems (and actually > implemented my suggested alternative) and there is no good way for a resize > which doesn't lead to all kinds of strange problems. My idea is that when the the matrix is used as a vector, when the matrix is resized, COLUMN(S) are added or removed, but NOT simple elements to a concrete row. Think something like: Matrix m; matrix_as_vector v(m); for (iter = v.begin(); iter != v.end(), iter++) {       matrix_column mc = *iter; // The contents of the iterator is a column of the matrix.       std::cout << "Column: " << mc << std::endl; } Joaquim Duran 2012/9/18 Oswin Krause <[hidden email]>: > boost range gives you automatically size(m). resize is a strange operation > for matrices in this context aside from m.resize(rows,columns) which is > already there. as long as you add both informations it is fine, but for > example in this case it is not clear what should happen: > > m.resize(0) //no columns-> empty matrix > m.resize(10) //10 columns, but how many rows? > > also a resize of a matrix row doesn't make sense, since all rows need the > same size and so on...i went through the same problems (and actually > implemented my suggested alternative) and there is no good way for a resize > which doesn't lead to all kinds of strange problems. > > Oswin Krause > > > On 2012-09-18 10:16, Joaquim Duran wrote: >> >> Thanks for your suggestion, but I should implement other operations >> like size and resize. >> >> Joaquim Duran >> >> >> 2012/9/17 Oswin Krause <[hidden email]>: >>> >>> The easisest way, which dos not require a poxy would be to use >>> boost.range >>> and implement a suitable >>> >>> begin(m) and end(m) along with the required iterator and typedefs. >>> >>> than your example would look like: >>> >>> main() >>> { >>>       matrix m; >>>       std::sort(begin(m), end(m), less_module); >>> >>> } >>> >>> On 2012-09-17 11:11, Joaquim Duran wrote: >>>> >>>> >>>> Sorry to send the example unfinished. Here it is completed. >>>> >>>> Example: Sort the columns of a matrix based on their module: >>>> >>>> using namespace boost::numeric::ublas; >>>> >>>> template >>>> bool less_module(const Vector& v1, const Vector& v2) >>>> { >>>>       return norm_2(v1) < norm_2(v2); >>>> } >>>> >>>> main() >>>> { >>>>       matrix m; >>>>       column_facade(m); >>>>       std::sort(m.begin(), m.end(), less_module); >>>> } >>>> >>>> Joaquim Duran _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Joaquim Duran Am Tuesday 18 September 2012 schrieb Joaquim Duran: > I'm developing classes to represent signals (think in DSP, AD > conversor,...) and implement operations to filter data, down-sampling > and related operations. Currently all classes are implemented based > on bounded_vector (to represent a signal or a sample of a set of > signals) and bounded_matrix (to represent a set of signals with the > same number of samples for each signal). The advantage of bounded > containers is that the resize operations (add or remove signals or > samples) don't generate new delete/operations. in this case I'd suggest to have a look at MTL4 http://www.simunova.com/en/node/24 . They provide a more general (and sometimes more abstract) interface to matrices. And (unfortunately) they have better performance with many operations ... Regarding uBlas: Long time ago there was a design decision to not handle a matrix as a set of vectors in order to avoid bad surprises when playing with the storage layout and iteration order. However, I'd gladly accept a new matrix view as list of vectors using boost:range . (Though I still believe that a few copies to/from a suitable data structure might get better performance than a complicated proxy of a full matrix ...) mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email] signature.asc (205 bytes) Download Attachment
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Hi, > Regarding uBlas: Long time ago there was a design decision to not > handle > a matrix as a set of vectors in order to avoid bad surprises when > playing with the storage layout and iteration order. However, I'd > gladly > accept a new matrix view as list of vectors using boost:range . So a matrix which also behaves as a range? or just a range adaptor which maps a matrix_expression to a range_of_vectors which isn't interpreted as matrix_expression anymore? In the last case i have the code lying around somewhere in my codebase and i just need to boostify it :). > (Though I still believe that a few copies to/from a suitable data > structure might get better performance than a complicated proxy of a > full matrix ...) I don't think that it costs a lot. Creating the matrix_row/matrix_column is free. And the dense layout of a matrix is ideal for cache based cpus. Maybe ublas won't have that much of an advantage from a dense structure since, as you said, it is not cutting edge performance at all. Having said that: are there any plans for an ublas2? Or something like that? At the moment the advise i hear a lot from people having looked at ublas is: "don't use it. There are many better libraries our there". I don't think that this is an ideal state for a boost library :/. Greetings, Oswin _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Gunter Winkler 2012/9/18 Gunter Winkler <[hidden email]>: > Am Tuesday 18 September 2012 schrieb Joaquim Duran: > >> I'm developing classes to represent signals (think in DSP, AD >> conversor,...) and implement operations to filter data, down-sampling >> and related operations. Currently all classes are implemented based >> on bounded_vector (to represent a signal or a sample of a set of >> signals) and bounded_matrix (to represent a set of signals with the >> same number of samples for each signal). The advantage of bounded >> containers is that the resize operations (add or remove signals or >> samples) don't generate new delete/operations. > > in this case I'd suggest to have a look at MTL4 > http://www.simunova.com/en/node/24 . They provide a more general (and > sometimes more abstract) interface to matrices. And (unfortunately) they > have better performance with many operations ... I know that there are many other libraries out there that implements algebra elements: armadillo (http://arma.sourceforge.net/), eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page),... but ublas was already included in boost. The code will execute in an embedded device so I was avoiding a new dependence with another library. I don't have to deal with 'very big' matrices, mainly 12x16 (12 signals x 16 samples). > Regarding uBlas: Long time ago there was a design decision to not handle > a matrix as a set of vectors in order to avoid bad surprises when > playing with the storage layout and iteration order. However, I'd gladly > accept a new matrix view as list of vectors using boost:range . I understand that, so I was asking for a proxy or a similar object. The main problem that I see is that operator* of iterators returns a const_reference and not a matrix_row or matrix_column, so IMHO new types of iterators should be defined. _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Oswin Krause Hello, Am Tuesday 18 September 2012 schrieb Oswin Krause: > Hi, > > > Regarding uBlas: Long time ago there was a design decision to not > > handle > > a matrix as a set of vectors in order to avoid bad surprises when > > playing with the storage layout and iteration order. However, I'd > > gladly > > accept a new matrix view as list of vectors using boost:range . > > So a matrix which also behaves as a range? or just a range adaptor > which maps a matrix_expression to a range_of_vectors which isn't > interpreted as matrix_expression anymore? 2nd option sounds good. > Having said that: are there any plans for an ublas2? Or something > like that? At the moment the advise i hear a lot from people having > looked at ublas is: "don't use it. There are many better libraries > our there". I don't think that this is an ideal state for a boost > library :/. Yes, you're right: * The uBLAS code is more than 10 years old, and little progress was made during last 5 years. * There is no active developer (just check the list of open issues ^^) * There is no active maintainer (There is a good chance that I "disappear" again when 1.52 is done ...) * There are really good alternatives out there which outperform uBLAS by far Thus we are stuck unless we find a university which develops yet another matrix library (compatible to uBLAS interface) or starts a full rewrite of uBLAS' internal logic. mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email] signature.asc (205 bytes) Download Attachment
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Hi, Here is my slightly adapted version of the range. I didn't find the boost coding guidelines so i just tried to fit it to other ublas headers(with limited success). Since i am not breathing standardese, I am not sure whether i am 100% correct in every aspect. Out of standard reasons, the implementation using proxy objects like matrix_row does not lead to a random_access_iterator even though it meets all traversal requirements. So algorithms like random_shuffle(and sort(?)) will work in practice but overeager compilers as for example MSVC will complain in debug mode. A solution to this is lying about the iterator category, but since i am a honest person, i don't ;) the implementation comes with a short test case, but i can also add a bit more if required. ---- Than maybe a note should be added to the documentation stating that uBLAS is outdated and should not be used for new projects. Maybe this leads to a bit of drive to the development ;). Even though i would volunteer to work on a new version and already have some ideas, uBLAS is just too big for me. It surpasses most BLAS Libraries in the amount features while calling itself "micro"-BLAS. (I think, this is one of the main sources of the problem. remove half of the features, call it nano-BLAS and ensure a good implementation). Gretings, Oswin On 2012-09-21 23:51, Gunter Winkler wrote: > Hello, > > Am Tuesday 18 September 2012 schrieb Oswin Krause: >> Hi, >> >> > Regarding uBlas: Long time ago there was a design decision to not >> > handle >> > a matrix as a set of vectors in order to avoid bad surprises when >> > playing with the storage layout and iteration order. However, I'd >> > gladly >> > accept a new matrix view as list of vectors using boost:range . >> >> So a matrix which also behaves as a range? or just a range adaptor >> which maps a matrix_expression to a range_of_vectors which isn't >> interpreted as matrix_expression anymore? > > 2nd option sounds good. > >> Having said that: are there any plans for an ublas2? Or something >> like that? At the moment the advise i hear a lot from people having >> looked at ublas is: "don't use it. There are many better libraries >> our there". I don't think that this is an ideal state for a boost >> library :/. > > Yes, you're right: > * The uBLAS code is more than 10 years old, and little progress was > made > during last 5 years. > * There is no active developer (just check the list of open issues > ^^) > * There is no active maintainer (There is a good chance that I > "disappear" again when 1.52 is done ...) > * There are really good alternatives out there which outperform uBLAS > by > far > > Thus we are stuck unless we find a university which develops yet > another > matrix library (compatible to uBLAS interface) or starts a full > rewrite > of uBLAS' internal logic. > > mfg > Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email] matrix_vector_range.cpp (4K) Download Attachment matrix_vector_range.hpp (5K) Download Attachment
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Hello, Am Saturday 22 September 2012 schrieb Oswin Krause: > Hi, > > Here is my slightly adapted version of the range. I didn't find the > boost coding guidelines so i just tried to fit it to other ublas > headers(with limited success). Since i am not breathing standardese, > I am not sure whether i am 100% correct in every aspect. > > Out of standard reasons, the implementation using proxy objects like > matrix_row does not lead to a random_access_iterator even though it > meets all traversal requirements. So algorithms like > random_shuffle(and sort(?)) will work in practice but overeager > compilers as for example MSVC will complain in debug mode. A > solution to this is lying about the iterator category, but since i > am a honest person, i don't ;) > > the implementation comes with a short test case, but i can also add a > bit more if required. see https://svn.boost.org/trac/boost/ticket/7411@Joaquim: does this solve your problem? mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email] signature.asc (205 bytes) Download Attachment
Open this post in threaded view
|

## Re: Matrix with vector interface.

 2012/9/23 Gunter Winkler <[hidden email]>: > Hello, > > Am Saturday 22 September 2012 schrieb Oswin Krause: >> Hi, >> >> Here is my slightly adapted version of the range. I didn't find the >> boost coding guidelines so i just tried to fit it to other ublas >> headers(with limited success). Since i am not breathing standardese, >> I am not sure whether i am 100% correct in every aspect. >> >> Out of standard reasons, the implementation using proxy objects like >> matrix_row does not lead to a random_access_iterator even though it >> meets all traversal requirements. So algorithms like >> random_shuffle(and sort(?)) will work in practice but overeager >> compilers as for example MSVC will complain in debug mode. A >> solution to this is lying about the iterator category, but since i >> am a honest person, i don't ;) >> >> the implementation comes with a short test case, but i can also add a >> bit more if required. > > see https://svn.boost.org/trac/boost/ticket/7411> > @Joaquim: does this solve your problem? > > mfg > Gunter > Yes, that was exactly asking for. Thanks. I'll try it. Joaquim Duran _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Gunter Winkler Hello all, I've been used the matrix row/column range successfully. Also, I've modified the code of Oswin and I've generalized a little: - Added reverse iterators.- Resize of matrix  * From matrix_row facade the number of rows of the matrix could be changed but not the number of columns.   * From matrix_column facade the number of columns of the matrix could be changed but not the number of rows. I would like to update the source code to ticked 7411 if there is no inconvenient for your part. I've followed the style of Oswin. Also, I've provided an executable but not tests cases, as Oswin did, Joaquim Duran2012/9/23 Gunter Winkler Hello, Am Saturday 22 September 2012 schrieb Oswin Krause: > Hi, > > Here is my slightly adapted version of the range. I didn't find the > boost coding guidelines so i just tried to fit it to other ublas > headers(with limited success). Since i am not breathing standardese, > I am not sure whether i am 100% correct in every aspect. > > Out of standard reasons, the implementation using proxy objects like > matrix_row does not lead to a random_access_iterator even though it > meets all traversal requirements. So algorithms like > random_shuffle(and sort(?)) will work in practice but overeager > compilers as for example MSVC will complain in debug mode. A > solution to this is lying about the iterator category, but since i > am a honest person, i don't ;) > > the implementation comes with a short test case, but i can also add a > bit more if required. see https://svn.boost.org/trac/boost/ticket/7411 @Joaquim: does this solve your problem? mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Joaquim, do you think you can request a pull of your code here? https://github.com/uBLAS/ublas/tree/ublas_feature0011_mvrange_interface_t7411/ Also a test case is necessary. Please follow a style like that: https://github.com/uBLAS/ublas/blob/ublas_feature0011_mvrange_interface_t7411/test/test_assignment.cpp since it integrates well with boost's auto regression test functionality.  If you don't provide a test me or David will have to make one that will take more time. -Nasos On 08/17/2013 11:36 AM, Joaquim Duran wrote: Hello all,  I've been used the matrix row/column range successfully. Also, I've modified the code of Oswin and I've generalized a little: - Added reverse iterators. - Resize of matrix   * From matrix_row facade the number of rows of the matrix could be changed but not the number of columns.   * From matrix_column facade the number of columns of the matrix could be changed but not the number of rows.  I would like to update the source code to ticked 7411 if there is no inconvenient for your part. I've followed the style of Oswin. Also, I've provided an executable but not tests cases, as Oswin did, Joaquim Duran 2012/9/23 Gunter Winkler Hello, Am Saturday 22 September 2012 schrieb Oswin Krause: > Hi, > > Here is my slightly adapted version of the range. I didn't find the > boost coding guidelines so i just tried to fit it to other ublas > headers(with limited success). Since i am not breathing standardese, > I am not sure whether i am 100% correct in every aspect. > > Out of standard reasons, the implementation using proxy objects like > matrix_row does not lead to a random_access_iterator even though it > meets all traversal requirements. So algorithms like > random_shuffle(and sort(?)) will work in practice but overeager > compilers as for example MSVC will complain in debug mode. A > solution to this is lying about the iterator category, but since i > am a honest person, i don't ;) > > the implementation comes with a short test case, but i can also add a > bit more if required. see https://svn.boost.org/trac/boost/ticket/7411 @Joaquim: does this solve your problem? mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] ```_______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email]``` _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 Hi, wow, that my code will actually get used.. :) Contrary to my comment in the code of the first version, i now think that the member of the iterator and matrix_column_vector should not be a Matrix* or Matrix& but a Matrix::closure_type or Matrix::const_closure_type depending on whether Matrix is const or not. This resolves the dangling reference problem for temporary matrix_expressions completely. with the current code and C++ 11 it is possible to write matrix A,B; auto matVec = make_row_vector(A+B); vector crasher= matVec(0);//A+B is already destroyed. which is not a good thing. This is easy to fix, given the following meta-function: template struct closure{     typedef E::closure_type type; }; template struct closure{     typedef E::const_closure_type type; }; and than replacing Matrix& matrix_; by typename closure::type matrix_; On 13.09.2013 15:31, Nasos Iliopoulos wrote: Joaquim, do you think you can request a pull of your code here? https://github.com/uBLAS/ublas/tree/ublas_feature0011_mvrange_interface_t7411/ Also a test case is necessary. Please follow a style like that: https://github.com/uBLAS/ublas/blob/ublas_feature0011_mvrange_interface_t7411/test/test_assignment.cpp since it integrates well with boost's auto regression test functionality.  If you don't provide a test me or David will have to make one that will take more time. -Nasos On 08/17/2013 11:36 AM, Joaquim Duran wrote: Hello all,  I've been used the matrix row/column range successfully. Also, I've modified the code of Oswin and I've generalized a little: - Added reverse iterators. - Resize of matrix   * From matrix_row facade the number of rows of the matrix could be changed but not the number of columns.   * From matrix_column facade the number of columns of the matrix could be changed but not the number of rows.  I would like to update the source code to ticked 7411 if there is no inconvenient for your part. I've followed the style of Oswin. Also, I've provided an executable but not tests cases, as Oswin did, Joaquim Duran 2012/9/23 Gunter Winkler Hello, Am Saturday 22 September 2012 schrieb Oswin Krause: > Hi, > > Here is my slightly adapted version of the range. I didn't find the > boost coding guidelines so i just tried to fit it to other ublas > headers(with limited success). Since i am not breathing standardese, > I am not sure whether i am 100% correct in every aspect. > > Out of standard reasons, the implementation using proxy objects like > matrix_row does not lead to a random_access_iterator even though it > meets all traversal requirements. So algorithms like > random_shuffle(and sort(?)) will work in practice but overeager > compilers as for example MSVC will complain in debug mode. A > solution to this is lying about the iterator category, but since i > am a honest person, i don't ;) > > the implementation comes with a short test case, but i can also add a > bit more if required. see https://svn.boost.org/trac/boost/ticket/7411 @Joaquim: does this solve your problem? mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] ```_______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email]``` ```_______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email]``` _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]
Open this post in threaded view
|

## Re: Matrix with vector interface.

 In reply to this post by Nasos Iliopoulos I'll pull the code with the tests. I'm writting them.2013/9/13 Nasos Iliopoulos Joaquim, do you think you can request a pull of your code here? https://github.com/uBLAS/ublas/tree/ublas_feature0011_mvrange_interface_t7411/ Also a test case is necessary. Please follow a style like that: https://github.com/uBLAS/ublas/blob/ublas_feature0011_mvrange_interface_t7411/test/test_assignment.cpp since it integrates well with boost's auto regression test functionality.  If you don't provide a test me or David will have to make one that will take more time. -Nasos On 08/17/2013 11:36 AM, Joaquim Duran wrote: Hello all,  I've been used the matrix row/column range successfully. Also, I've modified the code of Oswin and I've generalized a little: - Added reverse iterators. - Resize of matrix   * From matrix_row facade the number of rows of the matrix could be changed but not the number of columns.   * From matrix_column facade the number of columns of the matrix could be changed but not the number of rows.  I would like to update the source code to ticked 7411 if there is no inconvenient for your part. I've followed the style of Oswin. Also, I've provided an executable but not tests cases, as Oswin did, Joaquim Duran 2012/9/23 Gunter Winkler Hello, Am Saturday 22 September 2012 schrieb Oswin Krause: > Hi, > > Here is my slightly adapted version of the range. I didn't find the > boost coding guidelines so i just tried to fit it to other ublas > headers(with limited success). Since i am not breathing standardese, > I am not sure whether i am 100% correct in every aspect. > > Out of standard reasons, the implementation using proxy objects like > matrix_row does not lead to a random_access_iterator even though it > meets all traversal requirements. So algorithms like > random_shuffle(and sort(?)) will work in practice but overeager > compilers as for example MSVC will complain in debug mode. A > solution to this is lying about the iterator category, but since i > am a honest person, i don't ;) > > the implementation comes with a short test case, but i can also add a > bit more if required. see https://svn.boost.org/trac/boost/ticket/7411 @Joaquim: does this solve your problem? mfg Gunter _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] ```_______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email]``` _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [hidden email] _______________________________________________ ublas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/ublasSent to: [hidden email]