[eigen] solveTriangularInPlace |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: [eigen] solveTriangularInPlace
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 25 Jan 2009 22:55:48 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=hikzsUOhPazxxlUKXQ8OL8dvlL2BLDd7E9TBlGC+TF4=; b=MfefD7Q1ijQuDtzXQHuL0KPFWnMwF3GzetQ21x/YEeV9Jb0LXy7wuWvzH/n75u2crW u8jMtjQ3ZBLEIGFnVzvoHE2W/V7HBPl/ci3uegGH0BNLcwxTup6LgB8j+tRKO2CEvdUi jhEBfYptV5whINf72BbE29C7I2swWQeUMcpGA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=AqKIwj2FwVpllTuBE9LXU+zTt57r6byXaA0rAhCu6lHuMBGQQx8va7WE2ZRxM3BA2x w630Z09czPXHD0VBtgI09tVEpphqhOsK39Q/cKZHQrdQN9UU4HlskN2I1VjD9YXf6Jq1 rkF6aoiPrstJlvqio01hlpzRZmbkmC3xT74Eg=
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