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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: Re: [eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse*From*: <bernard.hugueney@xxxxxxxxxx>*Date*: Thu, 25 Nov 2010 18:23:35 +0100

Hi Gael, thanks for your support :)

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,andso I decided not to support it. Instead use iterators and/or, someI am fully aware that is dumb to iterate over the whole virtualmatrixhowever, the decision was not mine to make.Give that I had to enable some operations that result in a densematrix(e.g. "or equal" logical ops between sparse matrices where 0. <= 0.so my result is full) because i am reimplementing an alreadyexisting APIknew that the result would have to be large (i.e. dense) and slow to compute.Do you mean that the existing API implies random access to your (sparse) objects ? and you cannot extend to support iterators ?

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

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 basebecausethen 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

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,andI think this is even more powerful.

, behind an ugly proxy as explained above.

thank for the suggestion, but I' did not have much better luck with lastCoeff():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 typesdefaultvalue 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 nonzeros are true. Maybe this is what you were looking for whendeclaringa Eigen::Sparse<bool> ?

I'll think about it. Thanks for your continued help ! Best regards, Bernard

**References**:**[eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse***From:*bernard.hugueney

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

**Re: [eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse***From:*bernard.hugueney

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] [sparse] bool isMuchSmallerThan<OtherScalar>** - Next by Date:
**[eigen] naming conflict** - Previous by thread:
**Re: [eigen] [Sparse] element acces in a cwise unary op on an Eigen::Sparse** - Next by thread:
**[eigen] naming conflict**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |