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

[ Thread Index | Date Index | More Archives ]

On Fri, Sep 3, 2010 at 4:33 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> = A.solve(;
> Wait, there are 2 more problems here that I didn't anticipate before.
> The first problem is that 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 ?


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

Mail converted by MHonArc 2.6.19+