|Re: [eigen] [PATCH] Toeplitz matrix specialization|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] [PATCH] Toeplitz matrix specialization
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 29 Jan 2009 22:00:26 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ukiiJkgtkEOp0HLhoqXOhnmE6G3aoc8LksTnxWkzVYE=; b=XGWtUGRgC4J/JrflFiWeK2PZ3ChgGvvwpG2NVN5Zuql2Ig9IhI6RccIZUd2uZ0EjcM dw1GttYuOJ7Gcwh3VhWrCk062Wi8FlG7epahjhbjG3cStPLh1lNM80q8/ZfOyYK4gSsn STaaYF9016rrEtnU9KNdJr2DiGanN1Scq4XQk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=aD9FFQewXcLvFLfbQv7BWQhXMy7ivyrIWkjwL9AuT4MPUFphauCqZRAJ5t4XjfMJ/f 9+jLOuId1kXPyjbdNWEP+1TMYEPRITG6WgdAi4fOEEZg3Wbr/1juHZ6GREdU+fG+Vcz9 5Q4F+lf6M4SgBoHajiNed8xj1/yeGtjZdwtbo=
2009/1/29 Keir Mierle <mierle@xxxxxxxxx>:
> On Thu, Jan 29, 2009 at 11:36 AM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>> On Thu, Jan 29, 2009 at 7:55 PM, Keir Mierle <mierle@xxxxxxxxx> wrote:
>>> On Thu, Jan 29, 2009 at 6:40 AM, Gael Guennebaud
>>> <gael.guennebaud@xxxxxxxxx> wrote:
>>>> to start the debate I put some thougths on the wiki:
>>> The idea of making solveTriangular into Part::solve() sounds good to
>>> me. Right now the hetergeneous API for solving triangular systems is
>>> unfortunate. I vote to have solve() work as expected for triangular
>>> matrices with the same API as LU::solve, SVD::solve, QR::solve, etc
>>> (i.e. MyVec x; bool succeeded = my_triangular_mat.solve(b, &x);).
>>> Perhaps mymat.upperTriangular().solve(...)?
>> yes, exactly.
>>> Is there an excessive runtime cost to detecting a singular matrix in
>>> the triangular solver?
>> N comparisons, just like for Cholesky.
> Is it possible to have a bit to mark the martix as invertible by the
> user, to avoid the runtime cost? I.e. so that the check is optimized
> away when the bit is set. However, we should benchmark the cost of
> having the check to make sure it's high enough to want to remove.
We already have bits (which we control by calling
matrix.marked<someBit>()) for triangularness, unit-diagonal,
zero-diagonal, so why not one more bit, and I know I have a use case
in the LU solver where I can guarantee that my triangular expression