Re: [eigen] solveTriangularInPlace

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Sun, Jan 25, 2009 at 10:55 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Hi,
>
> here is a patch that i am ready to commit, but i am not sure you'd
> like it, so let's discuss it.
>
> It improves LU::solve() by using a call like this:
> solveTriangularInPlace(c.corner(...));
> The problem is that currently solveTriangularInPlace takes a non-const
> reference, so the c++ compiler won't let me pass a temporary object
> here.
>
> We already met that problem for swap() and the solution we're using so
> far is to let swap take a const reference, and then const_cast it.
>
> The attached patch makes solveTriangularInPlace behave similarly.
>
> If you don't like it, the alternative is to construct named
> expressions and pass them to solveTriangularInPlace. But then we
> should be homogeneous and do the same for swap() which would mean
> goodbye to m.row(i).swap(m.row(j)) which frankly i think would be too
> bad. I much rather prefer to fail to honor constness here and document
> that. So, OK to commit?

I'm ok for that.

> Another thing while I'm here. solveTriangularInPlace takes blocks, and
> even blocks inside blocks. So when passed a corner(), it's using 2nd
> order blocks and even 3rd order blocks. This has been confusing
> compilers in the past. Here's a proposal to deal with that in a
> generic way: override methods such as block(), start(), corner(), etc,
> in the Block class, to return a plain block instead of a Block<Block>
> whenever possible. How useful do you think that can be?

this sounds to be a good idea. Actually this is more or less already
the case for block of expressions having the DirectAccessBit flag
because in that case Block is just like a Matrix. but for expressions
like (A+B).block().col(), yes this would probably help a lot the
compiler.


>
>