| Re: [eigen] Why no LU::solveInPlace()? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Why no LU::solveInPlace()?
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 3 Sep 2010 16:47:33 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=a3Dbucqgblgx+iiH36Um1UIORhsfsZC5LksUH43lYOg=; b=Gih33qEUNAx551NfEOtuwvOzM+L9hPQ+Z35XdeHipcm9VcshvaVTsAQchhk2eOjYCM 4/z1Hp6HcwxbfT2yHEvCTLzBYMQyapo+JNOFxy0BTdoPzz/f/UU2WbIxTLahCOyPSBmk 9NjAhpLI5FBR5M///KohdQFX79EMt1SRXwKcE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=SXXK3/kyj6bk5XcsVGAwg+6lLBwf/ILhSE4S5GsBx3/8LlBdkAjpNmJatEyRyyuBGT E/LzWjHYLqpAUH084fTMzqDzodGBn59dKSRgBmTtW4YTSuaJVhrlEoOIELp9FKgv+rDu JOcxVJ5PjnzVomRd8czm2txxkBaLpZ266J9iY=
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 ?
gael
> 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.