| Re: [eigen] Feature idea: coeffRef() ---> setCoeff() |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Feature idea: coeffRef() ---> setCoeff()
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 15 Aug 2010 02:30:33 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iXBFKnYeGLDh6xU95QJrAfTISywrLeekBmdMHVMgMuU=; b=ee96Yuw/ilUMG4jOTzqq0TzRTXqHcQrtzhyh2cBRlxCZXxe9s18coK7ZDE94+00CSc pTWq+OjdKVkxiFod0FUR0FQz27KxoIA1y3HmeyDeVMTfjee54ffsptwidy9tXLAZ9mmy +QyjMi/1Gk8gKvGFacB0arHvgaA/SCMKViL5w=
- 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=uxGNId2rNfgKi3YzYoKyw417HvTZulqvToYFjytzh0w8HlFJsCmHJBeR52GJMFut9a Z/ILmieSWaDu7RExudvDd+iQQCcScOCbq6NGIdPPCXM7q3tPc4RbFiP8pFAod7lEMKPg b9zROAqJ/qYSwkewH2zvebOirDM7y8GKZZJSI=
2010/8/14 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Fri, Jul 30, 2010 at 6:56 PM, Manoj Rajagopalan <rmanoj@xxxxxxxxx> wrote:
>>
>>
>>
>> On Friday 30 July 2010 10:30:19 am Benoit Jacob wrote:
>>> 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
>>>
>>
>> That's exactly what I settled into :-) The wish for a neater, more direct
>> expression closer to the math sparked off this entire line of thought :-)
>
> your initial mathematical expression was:
>
> L21 L11^H = A21;
>
> =>
>
> L21 = A21 L11^-H
>
> so the most direct Eigen version is:
>
> L11.adjoint().solveInPlace<OnTheRight>(L21);
>
> which is far less ambiguous than any other solution.
Ah, awesome: I didn't know that we had this OnTheRight option. My more
complicated variant with conjugate() was just trying to work around
not having this.
Benoit
>
> gael
>
>>
>> -- Manoj
>>
>>
>>
>
>
>