Re: [ublas] Is coordinate_matrixelement assignment/insertion broken in 1.42?

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_begin();
insert_lazy( element ) // ok, no sorting 
insert_lazy_end();

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 
container, and 

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. 

Cheers,

Rutger