Subject: Re: [ublas] Is coordinate_matrixelement assignment/insertion broken in 1.42?
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2010-03-05 02:59:24
Gunter Winkler wrote:
> This was necessary to avoid unexpected performance problems when the
> matrix is used without care. In order to verify whether the element
> (i,j) already exists or not it is necessary to sort the already existing
> elements. Thus the usually const find_element(i,j) method must be able
> to sort() the arrays. That's why most of the private variables are
> declared "mutable". The decision to use mutable was made because most
> users simply used coordinate_matrix as drop-in replacement for
> compressed_matrix or mapped_matrix. The alternative possibility was to
> have a log(n) lookup in the sorted part plus a loop over the unsorted
> part because the coordinate matrix may contain the same element (i,j)
> more than once.
> What is you opinion? Would it be better to have a real constant
> find_element() and require the user to call sort() before accessing
> elements by index?
Well, I would expect insert() to call sort(). Something like (sketchy),
insert( element ) // post: all sorted
insert( begin, end ) // post: all sorted
insert_lazy( element ) // ok, no sorting
where insert() is a composition of insert_lazy() would be more clear to me.
The reason I am opposed implicit lazy stuff, besides the added complexity,
is because of performance problems -- lazy stuff works all nice in one
thread, but in two threads you might want to have multiple readers to a
at( i, j ) const
kind of "promises" that multiple concurrent reads are OK, but in reality
they are not, and will lead to undefined behavior. I.e., the code is not
doing what the interface is saying its doing.