Re: [eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse

[ Thread Index | Date Index | More Archives ]

Hi Gael, thanks for your support :)

On Thu, 25 Nov 2010 17:36:59 +0100, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
On Thu, Nov 25, 2010 at 3:50 PM, <bernard.hugueney@xxxxxxxxxx> wrote:

Hi Gael,
Thanks for your answer.

On Thu, 25 Nov 2010 13:13:59 +0100, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:

Random access to a sparse matrix is inherently very inefficient, and
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 matrix
however, the decision was not mine to make.
Give that I had to enable some operations that result in a dense matrix
(e.g. "or equal" logical ops between sparse matrices where 0. <= 0.
so my result is full) because i am reimplementing an already existing API
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 supposed to use them with the sparse matrices, hence the coeff() and coeff() calls. Furthermore, I sometimes have to do it on .cast<> of the sparse matrices :(

Otherwise, if what you want is to be explicitly aware of the zeros,
what about:

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 because
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 user. such as a .withSlowRandomAccess() taht would provide a proxy with the coeff() and coeffRef() (you need to keep the same member function anmes to allow
generic programming).

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, and
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 default
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 declaring
a Eigen::Sparse<bool> ?

I'll think about it.

Thanks for your continued help !

Best regards,

Mail converted by MHonArc 2.6.19+