|
|
Ublas : |
From: Gunter Winkler (guwi17_at_[hidden])
Date: 2005-05-02 04:22:22
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.
> 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 ;-)
> 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?
> More complaints: the ublas docs on the official boost pages are broken.
> Some pages don't exist anymore. I am still missing a comparison operator
> for matrices (operator==).
There is no way to usefully define an operator== of float matrices. But there
is already the (still undocumented?) equal function used by some
BOOST_CHECK(..) macros. Try this one. Alternativly you can always use
norm_inf(A-B) which returns zero if both matrices are equal.
> 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.
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.
> 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.
Why don't you try to understand ublas and fix the bugs you found here? It's
not as complicated as it looks at first glance.
> Greetings, Max