|Re: [eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
Hi Gael, thanks for your support :)
On Thu, 25 Nov 2010 17:36:59 +0100, Gael Guennebaud
On Thu, Nov 25, 2010 at 3:50 PM, <bernard.hugueney@xxxxxxxxxx>
Thanks for your answer.
On Thu, 25 Nov 2010 13:13:59 +0100, Gael Guennebaud
Random access to a sparse matrix is inherently very inefficient,
so I decided not to support it. Instead use iterators and/or, some
I am fully aware that is dumb to iterate over the whole virtual
however, the decision was not mine to make.
Give that I had to enable some operations that result in a dense
(e.g. "or equal" logical ops between sparse matrices where 0. <= 0.
so my result is full) because i am reimplementing an already
knew that the result would have to be large (i.e. dense) and slow to
Do you mean that the existing API implies random access to your
(sparse) objects ? and you cannot extend to support iterators ?
It depends, but yes, sometimes receive arrays of coords as args and I'm
to use them with the sparse matrices, hence the coeff() and coeff()
Furthermore, I sometimes have to do it on .cast<> of the sparse
Otherwise, if what you want is to be explicitly aware of the zeros,
I also want that for when I do not receive the coords as args but have
to do the full
traversal, so thanks for the tip.
but I feel that won't address your issue, right?
Part of it, cf supra.
Actually, I'm reluctant to add a coeff() method to matrix base
then it will become too easy to mix dense/sparse objects in a very
very inefficient way... I'm even not sure that was a good idea to add
coeff() method to SparseMatrix and the likes.
I do understand. Howeever, sometimes it might be needed, so I think
the best would be to provide them with an ugly syntax that warns the
such as a .withSlowRandomAccess() taht would provide a proxy with the
and coeffRef() (you need to keep the same member function anmes to
On the other hand I also agree that if we support coeff() for sparse
object with storage, it makes sense to do so for unary expressions,
especially for trivial ones like your cast example ! For binary
expressions that's another story because the sparse pattern change.
So maybe here is a compromise:
- remove the coeff() and coeffRef() methods.
- instead add a searchCoeff(i,j) method returning an iterator. It
would evaluate to false if the coefficient does not exist. Otherwise
one could overwrite the value doing it.value() = x;
This solution clearly say that this operation is going to be slow,
I think this is even more powerful.
nice solution, but I'd also like to keep the coeff(), coeffRef()
interface for generic programing
, behind an ugly proxy as explained above.
thank for the suggestion, but I' did not have much better luck with
oops, indeed, sorry, it is implemented only for objects with storage.
Any chance that it might bet implemented ?
Btw, à propos Eigen::Sparse<bool> :
- it would be nice to be able to set the default value to «true».
I see your point. but on the other hand for other scalar types
value of non zero is zero, so...
Actually I plane to support SparseMatrix<void> where only the pattern
will be stored. This is equivalent to a "Sparse<bool>" where all non
zeros are true. Maybe this is what you were looking for when
a Eigen::Sparse<bool> ?
I'll think about it.
Thanks for your continued help !