Re: [eigen] Feature idea: coeffRef() ---> setCoeff()

[Manoj Rajagopalan <rmanoj@xxxxxxxxx>]

On Friday 30 July 2010 12:08:42 am Benoit Jacob wrote:

> oh... i see. I guess that you omitted setCoeff in the above line, by
> the way, so you meant:
>
> A.selfadjointView<Lower>().setCoeff(j, j+1, value); // note: write to
> upper triangle
>
> so this would write 2 coeffs at once in A ? Why not. Indeed that cant
> be done with coeffRef. But I don't adhere to your rather complex plan
> of generally allowing to write to Conjugate expressions, this is not a
> prerequisite for that, we could just implement setCoeff in
> selfadjointView, where it is useful, without implementing it in stuff
> like conjugate() which IMO just don't want to be writable expressions.
>
> This would be much simpler --- the patch could be just a few kB's.
>
> But again, coeffRef() is definitely not going away.
>
> Benoit

In my implementation of LLT on self-adjoint matrices with compact triangular 
storage, which involves partitioning the matrix into 2x2 block form, one step 
leads to an Eigen expression of the form,

    L11.solveInPlace(L21.adjoint()); // L11 is triangular-view

This expression compiles but I'm not sure it will work the way I want it. 
Basically, I want the adjoint of the computed solution to be written back to 
memory because, the mathematical expression I end up solving looks like:

      L21 L11^H = A21;  // L11 triangular, known, A21 known, superimposed L21
=> L21^H = L11^{-1}  A21^H

    If I required transpose() instead of adjoint(), the transpose of the 
solution gets written back as expected because Transpose<> allows 
write-through. But the conjugate component of the adjoint functor is declared 
const so I am not sure the solutions is transposed AND conjugated before 
write-to-memory for adjoint().

This got me thinking about having a Conjugate<> wrapper like Transpose<> that 
writes the reverse-transformed value into memory so that we get what we 
expect during read-back.

I would find this feature useful. I thought some others might too. 
Implementing Complex<> should be simpler than Transpose<>. What you are 
referring to as hard might be propagating this through the library and 
testing it. But sure, setCoeff could co-exist with coeffRef().

thanks,
Manoj