|Re: [eigen] Why no LU::solveInPlace()?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Why no LU::solveInPlace()?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 3 Sep 2010 10:50:04 -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=25j/gnS/Cs3tEFayXYVq9ayKD5dCsZCvvJkskt0CHIA=; b=w4DG8R//VYGA2OGWn7ICWN2vLHvRo7iriodHM4su2/HRpJ3+/dfRX4heue32F0gluy NgyCidURPtqs1jQoptI6XIE6VkfPkm/q1jAZg2Zfg9SGcrr1hh5Ih7xhkX0Mskh+foGm oOU/kCZ/EUipjarTL7h4eE2efTasvQEftBOzI=
- 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=MpnQQ/3mHpOYpoMuhUm+0Gak9QUCYxnvU2qcBzJU9uPE6nDDCeN2Q3XlDpKqMqhPDp MnAV1QxuKGbb0voo30EItr64kxbVZK6amHSW6UDnzN7/Bs5VqvcolNPBErQafg2GLEqq 3tsAJEEFkqHsGV2+oTDw0uwQP49gCS2apAVvM=
2010/9/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Fri, Sep 3, 2010 at 4:33 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> B.foo().bar().long().expression() = A.solve(B.foo().bar().long().expression());
>> Wait, there are 2 more problems here that I didn't anticipate before.
>> The first problem is that B.foo() will return a new (lightweight)
>> expression object everytime, so pointer comparisons will fail.
> no no, I compare the data pointers (just like for debugging
> transpose), not the addresses of the temporary expressions. I guess
> this also answer your second concern ?
ooooh right, thanks.
>> The second problem is that just taking a pointer to an expression
>> object could easily prevent the compiler from "optimizing away" this
>> object. I know we are already doing that in transpose() aliasing
>> detection but that is just in debug mode, right? Here we're now
>> talking about adding that also in non-debug mode and that could be a
>> bigger issue. Although I guess that the cost of constructing the
>> expression is totally negligible in this particular case (solving
>> being expensive enough) I thought that was worth bringing up. In the
>> case of complex enough expressions and small fixed sizes, this could
>> easily become non-negligible.