|Re: [eigen] Pivoting for LDLT|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Pivoting for LDLT
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 3 Feb 2009 14:53:04 +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=kUxQspdJUjYtlGLqGizZC2BLxcmZY7NUOiSDa2XAMF0=; b=nXgT4m1ziNg/mFO98+nSMxyjQr/Mqh2pHzInRcxONKxhxhGEwW+V2RF6HKIHVbJGxA fg5RfJwRlM7jjcJPfjUF9zfUDrTfnks/d+0iix5OpiWTzHZwnj1IZUTbZXRrltIDy9QP jXj9DQEwSK5GAcE4+UDd6ns1Y9o4FW+YRIzFA=
- 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=u6905pG18pqMk0PtBzDX8V0yDoBjM5rLJLsYzwSrqXv9vwBngqa20ytnImqCbfEmIv CirICpe6zYdUMHuWhP6LvySTpno4unpNxdqcPPdbspz/wwZgYaKU1PkvnWYg6kc+awDr 5jtJzjwLbcB1WVBOITI7h7d/DxRK3TLbL1GvM=
2009/2/3 Keir Mierle <mierle@xxxxxxxxx>:
> I did some more experiments, and I'm convinced. Not only does the example
> you give here fail badly with nopivot, the nopivot version is not
> rank-revealing in the semidefinite case. What's left is the API decision;
> should I make pivoting a template option (enabled by default)? Since I doubt
> many LDLT objects get instantiated this is probably ok.
I've been thinking about this for LU and I think that pivoting or not
is really such a big difference that it's best handled as 2 different
However in your case I doubt that the non-pivoting option is needed:
if the user knows no pivoting is needed, he might use the LLt, which
is fast and non-pivoting, right? So a non pivoting LDLt would have to
fit in a very small niche market between the LLt and the pivoting
> However, now the matrix L is not meaningful without the permutation matrix.
> This is not an issue for solving, but could be for users of .matrixL(). On
> the other hand, this is currently the case for LU.
It is meaningful, only you have to say that the matrix is no longer
decomposed as LDLt but rather as
(PL)D(PL)t where P is a permutation matrix. (At least that's how i
understand pivoting LDLt, I haven't yet looked at the code).
In the full LU, I ended up removing the matrixL() and matrixU()
methods but for another reason: in the rectangular case, matrixL() was
really really not meaningful at all. Here, I'd say your matrixL() is
very meaningful, it's just that it must not be confused with PL.
That said, i decided in LU to only provide a method matrixLU() and let
the user do his own cooking with part() to get L and U. Maybe this
approach can be considered also for other kinds of decompositions
(again, what made it especially necessary in LU was that a matrixL()
returning a Part was completely meaningless in the rectangular case).
> p.s. the blocked LDLT which can deal with indefinite matrices is a different
> algorithm (D is block-diagonal with 1x1 and 2x2 blocks), and I am not
> targetting it because I only need to solve semidefinite systems stably.