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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Fri, Sep 3, 2010 at 4:50 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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.

in case you' want to look for it, let me also precise that currently
this optimization - yes this "if" is an optimization - is done at the
level of the Permutation product.

For LLT solving (Ax=b), we start by doing:

x = b;

and then do inplace triangular solving,

so ideally this copy should be avoided at the level of operator=
itself, but I feel you won't agree me putting a if there though again
this would be an optimization...

The if would be an overhead if and only if the types matches but the
objects are not the same as in:

Matrix2d A, B;

A = B;

or (more worrying because more realistic):

Vector2d foo();
Vector2d a;
a = foo();

I will check how the compiler deal with that and let you know....

gael

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