Re: [eigen] Contributing condition number estimator |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Contributing condition number estimator*From*: Rasmus Larsen <rmlarsen@xxxxxxxxxx>*Date*: Tue, 24 Nov 2015 08:37:54 -0800*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HyoPU0e+WQNZdLekIPdAE2QsG9HzHm8nqNwz48N3Qd8=; b=ez0Fq5ZVg9L/E0Of+Xv4+dP5wL87Shu63A7mDVZbIsS+XcyXFx93t37a1G/lzJvJkm PQfxqLMiSUNNpilN+IdGxz+f66J+zv9DT1FptVASK3pbiSAdFcKssJN7B811DZ8PP6rv TM1+Im/Eg7jx09TS7lgWz+2iFgdU4M2zl8wG20EN9YfHPW/6uVvHi89mndEGCkSFHk+V c6PGEvhgcHg3r5bVhBLYsxShZYoQG2uH8MNcYcfQeliD1Ph4N+ctFrq+hOU+gPAfjedT ykhJp8GXd6YWXbfzMliOpUBC6y0lN4MfUDN5WjkOjDCpoRzXVc8xNrSbOl+fKA+WQU2t L69A==

Hi,

Thanks for the quick response.

On Tue, Nov 24, 2015 at 6:04 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

Hi,On Tue, Nov 24, 2015 at 1:22 AM, Rasmus Larsen <rmlarsen@xxxxxxxxx> wrote:I would like to contribute a feature that I find lacking in Eigen's linear algebra code: Efficient condition number estimation.yes, this would be a nice addition.The first step that I would like you opinion on, is to how to add functionality to the non-symmetric decompositions (specifically FullPivLU and PartialPivLU) for solving the system adjoint system A^* x = rhs. Here I see two approaches:a) Add new methods "solveAdjoint" in the LU classes that return a new type solve_adjoint_retval internal type in Solve.h. (I have this implemented already. Benoit Jacob reviewed it.)there is not solve_retval pseudo expressions anymore, but see below...b) Add a template parameter "bool Adjoint" (with default value false) to existing solve methods in the LU classes (and pass it to solve_retval etc.).I guess that the cleanest way would be to make the public API looks like:1) b = lu.solve(x);2) b = lu.transpose().solve(x);3) b = lu.adjoint().solve(x);where PartialPivLU::adjoint()/transpose() would be implemented as in DenseBase<>, i.e., transpose() would return a Transpose<PartialPivLU>.

That would indeed be a more elegant solution.

The general idea is that a decomposition object should resemble as close as possible to a matrix but with a special storage scheme (product of factors)...then via a few specializations of TransposeImpl<> and Solve<> we can easily forward the above calls to:1) lu._solve_impl(x, b); // already done through the class Solve<> that generalize solve_retval2) lu._solve_impl_transposed<false>(x, b);3) lu._solve_impl_transposed<true>(x, b);I can help with that internal magic, and in the meantime you can directly implement and call _solve_impl_transposed.

Sounds good. We are still on 3.2.7 at Google, so I will have to prepare separate patches. But as you say, I can call something like _solve_impl_transposed directly in my 3.2 code.

The second step would be to add a method "Scalar rcond()" to all the decomposition classes returning the estimate of the reciprocal condition number.sounds good..Gael

**Follow-Ups**:**Re: [eigen] Contributing condition number estimator***From:*Rasmus Larsen

**References**:**[eigen] Contributing condition number estimator***From:*Rasmus Larsen

**Re: [eigen] Contributing condition number estimator***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Contributing condition number estimator** - Next by Date:
**Re: [eigen] Contributing condition number estimator** - Previous by thread:
**Re: [eigen] Contributing condition number estimator** - Next by thread:
**Re: [eigen] Contributing condition number estimator**

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