[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/ |