Re: [eigen] Feature idea: coeffRef() ---> setCoeff()
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] Feature idea: coeffRef() ---> setCoeff()
• From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
• Date: Fri, 30 Jul 2010 10:30:19 -0400
• Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WqZ7Yvgf98BeW0zvF2bMCC/2XF1BST7BfZ2I3bRqVZ3R9oRVd2hOGKiz79I13FG+MW JPc6QQ6uK+0sGNKLoK78kE0OHXEO2TgWdjljeTXIQl5KwZRw9IpEHp5iYb3nKO+DI3gw udgV8dVvb65fyH77UAGT/66abUErEwh10FeJI=

```2010/7/30 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

Oh, if that's what you wanted to do, why don't you just apply complex
conjugation here, so this is equivalent to doing:

L11.conjugate().solveInPlace(L21.transpose());

Now you're good to go, because transpose() returns a writable
expression which can perfectly be used in solve-in-place.

Benoit

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

```

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