[eigen] Re: solveTriangularInPlace

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

forgot the attachment...

2009/1/25 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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?
> 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?
> Cheers,
> Benoit

Attachment: diff
Description: Binary data

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/