Matrix with vector interface.

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Matrix with vector interface.

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?

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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Oswin Krause
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 <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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Gunter Winkler
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<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

_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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, 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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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 <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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Oswin Krause
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 <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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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 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 <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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Gunter Winkler
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/ublas
Sent to: [hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

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? 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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Gunter Winkler
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/ublas
Sent to: [hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

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.


----
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/ublas
Sent to: [hidden email]

matrix_vector_range.cpp (4K) Download Attachment
matrix_vector_range.hpp (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

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]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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 Duran


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

_______________________________________________
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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

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 <[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/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]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Oswin Krause
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 meta-function:

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:
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 <[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/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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Joaquim Duran
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 <[hidden email]>
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 <[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/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/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matrix with vector interface.

Nasos Iliopoulos
In reply to this post by Joaquim Duran
Joaquim,
I  merged your pull request into https://github.com/uBLAS/ublas/tree/ublas_feature0011_mvrange_interface_t7411, but it seems that the unit test fails for sparse matrices. Before I start investigating it, do you have any ideas why?

Please note that I made some minor changes for debuging reasons in test_matrix_vector.cpp.

-Nasos


Date: Sat, 17 Aug 2013 17:36:32 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [ublas] Matrix with vector interface.

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 <[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/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]
12