Re: GSOC 2013

"oswin krause" <[email protected]>
Newsgroups gmane.comp.lib.boost.ublas
Message-ID <[email protected]>
Sorry, I don't want to spam.

Here a list of suggestions which I find way more important than unifying 
matrices and vectors:

1. change the way iterators work for matrices, as already outlined here
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?UBLAS_Matrix_Iterators 

over 6 years ago.

The reason why this should be important? I have an application where I 
need to compute a lot of distances between vectors and matrix-rows (in 
row-oriented matrices). If the arguments are sparse (and I use a 
compressed matrix), i am more than factor 3 slower than the simple 
for-loop using the internal arrays of the compressed matrix. The main 
bottle neck is CompressedMatrix::find for the two queries of the 
begin/end iterators, which should in this case be only 2 memory lookups 
but is ridiculously slow in the ublas design. But even afterwards, this 
leads to a much slower iterator than just iterating the arrays.

When I wrote a workaround wrapper for that which takes a matrix-row of a 
compressed matrix and implements the sane iterator for that, i get the 
expected speed-up(minus a small overhead for the wrapper itself...).

2. change the way matrix-expressions are evaluated. In the current 
iterator based design, not even transposing a matrix can be done fast. I 
am currently playing a round with a design which interprets expressions like

A+= 3.0*subrange(expression,a,b,c,d)

as
expression.plusAssignTo(A,a,b,c,d,3.0);

and suddenly everything can be implemented very easy and fast (and also 
very general).

3. proxies of "real" vectors/matrices(i.e. vectors which can be left 
hand side arguments) should make use of the memory layout of the 
underlying vector/matrix. The created wrappers should be interchangeable 
when the underlying object has the same memory layout. That means taking 
a matrix row of a row-major dense matrix should lead to the same proxy 
as taking a subrange of a vector. Moreover a vector should be implicitly 
convertible to it's wrapper type.

reason:
struct Foo{

virtual void doSomething(dense_vector_proxy<double> const& wrapper);
};
Foo foo;
blas::matrix<double> m;
blas::vector<double> v;
foo.doSomething(row(m,0));
foo.doSomething(v);

This is of course only my opinion, but these are the things which cost 
me the most time right now.
_______________________________________________
ublas mailing list
[email protected]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.