Subject: Re: [ublas] Is coordinate_matrixelement assignment/insertion broken in 1.42?
From: Gunter Winkler (guwi17_at_[hidden])
Date: 2010-03-03 17:35:40
Rutger ter Borg schrieb:
> Thomas Klimpel wrote:
>> Very helpful, thanks. I had misread "MSVC2008SP1" as MSVC8SP1 = "Visual
>> Studio 2005". However, I don't have time to try to reproduce this now (->
> I have another idea of what it could be. The compressed_matrix is doing
> modifications by means of sort() in an observing function (which should be
> forbidden, by the way!). This gives faster inserts for someone who is
> inserting element-by-element -- the reason why STL provides iterator ranges
> for bulk inserts. I.e.,
> // modifiers
> insert( element )
> insert( begin, end )
> // observers
> at( i, j ) const
> // further down the class
> // need to counter the const of the observer by adding mutable
> mutable some_container;
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?
BTW: the sorted_ flag is obsolete because the relation sorted_ ==
(filled_ == sorted_filled_) must always be valid.
__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4913 (20100303) __________
E-Mail wurde geprüft mit ESET NOD32 Antivirus.