
12

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 <typedef Vector>
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]


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 <typedef Vector>
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]


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 20120917 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 <typedef Vector>
> 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]


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<ublas::vector<double> > > gvov;
>
> this class has a data() function which returns a reference to the
> storage array (which is a vector<vector<double> >)
>
> 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, downsampling
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
downsample 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]


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 20120917 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 <typedef Vector>
>> 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]


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 20120918 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 20120917 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 <typedef Vector>
>>> 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]


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<Matrix> 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 20120918 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 20120917 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 <typedef Vector>
>>>> 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]


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, downsampling
> 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]


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]


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, downsampling
>> 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]


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]


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 nanoBLAS and ensure a good implementation).
Gretings,
Oswin
On 20120921 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]


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]


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]


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<double> A,B;
auto matVec = make_row_vector(A+B);
vector<double> crasher= matVec(0);//A+B is already
destroyed.
which is not a good thing.
This is easy to fix, given the following metafunction:
template<class E>
struct closure{
typedef E::closure_type type;
};
template<class E>
struct closure<E const>{
typedef E::const_closure_type type;
};
and than replacing
Matrix& matrix_;
by
typename closure<Matrix>::type
matrix_;
On 13.09.2013 15:31, Nasos Iliopoulos wrote:
_______________________________________________
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]

12
