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

[<bernard.hugueney@xxxxxxxxxx>]

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
> > compute.
>
> 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
> > 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 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,
Bernard