Re: [eigen] Why no LU::solveInPlace()?

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

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

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