|
|
Ublas : |
From: Michael Stevens (mail_at_[hidden])
Date: 2005-05-02 12:04:19
On Monday 02 May 2005 11:22, Gunter Winkler wrote:
> On Monday 02 May 2005 00:08, Max Weinberg wrote:
> > Hello,
> > there are some bugs in the current ublas HEAD. compressed_matrix seems to
> > be quite broken. Writing simply:
> > compressed_matrix<double> mat(2,1);
> > mat(1,0) = 1.0;
> > triggers an assertion. The assertion is most likely wrong.
>
> This line of compressed_matrix::storage_invariants
> BOOST_UBLAS_CHECK (filled1_ > 0 && filled1_ <= capacity_ + 1,
> internal_logic ());
> seems unnecessary, since index1_data_ has always size = size1_ + 1
>
> The correct line is:
> BOOST_UBLAS_CHECK (filled1_ > 0 && filled1_ <=
> layout_type::size1 (size1_, size2_), internal_logic ());
>
> please change this on CVS.
Thanks for the quick fix Gunter. I was working on similar lines. I try and get
this into CVS tomorrow.
> > An amazing result of an addition can be seen here:
> > compressed_matrix<double> mat(10,3);
> > mat(6,0) = 1.;
> > mat(7,1) = 1.;
> > mat(8,2) = 1.;
> > cout<<mat<<endl;
> > mat(9,0) += 42;
> > cout<<mat<<endl;
>
> There was a line changing filled1_ in reserve(). Looks like
> storage_invariants() work quite well ;-)
Always good when the code asserts!!
> > After the +=, the ones are compressed into one row. I guess something is
> > wrong in insert_element, but I don't understand it. Shouldn't errors like
> > that be caught by some unit tests?
>
> Why don't you contribute some more tests?
Interesting that it does pass. As I see it the failure depends on the exact
order of inserts. Something hard to really test for exhaustively.
>
> > More complaints: the ublas docs on the official boost pages are broken.
> > Some pages don't exist anymore.
That is odd. I think they were fine at release time. Any pointers to which
pages?
> > One more thing that I don't like is that
> > whenever a sparse_matrix_element is constructed, the default constructor
> > of value_type will be called, since value_type is a data member of
> > sparse_matrix_element. This can be quite costly.
The element proxies are a big design trade off. If you have a expensive to
construct element object they are definitely a mighty overhead. Happly that
is not the case for any of the objects we normally deal with in Linear
algebra.
> Do you have an idea how to avoid this? The sparse_matrix_element must be
> able to store an instance of value_type. The IMHO only way to optimize this
> is to use some pool of sparse_matrix_elements. But I think its better to
> change the algorithm to avoid using references.
Another possibility would be to have an instance of the spare_matrix_element
in the sparse matrix. If you do not require thread safety this could be a
static member.
>
> > Some more bugs are listed below. I noted also a lot of type conversion
> > warnings. Final words: Right now, I am quite disappointed with ublas and
> > I think the next thing I will do is to write my own crappy hand-crafted
> > sparse matrix class. At least I can fix it on my own.
Interesting you mention type conversion warning. uBLAS normally compile
warning free. What types are you storing?
Michael