Re: [eigen] Design for integrating different decomposition approaches |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Design for integrating different decomposition approaches*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Wed, 13 May 2009 09:34:04 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=vQDQkrf7ugoWQIvUIN9cZH7ZHbtWZPE3oAlB+g6pCxw=; b=s+JzNeFjNQ3SpIQXSPu+yJx1qssrqHxwIbayNNXn39dBt4IZA2CJGhub0F3NUqfbsH 9Ye/0SWd1ynvt0u1m4nf82SOWalpX2ypbqChZoR9j2zFIkXOuZERwExSxwSlzqgx/JF+ SwCNcAUEuILhRKyw1vamP9osP20FIEE/z4Moc=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AGMxskbjYGnGiUlsyH/ZXczkuQmmqNjH/fKZPuWP64lJ3Tzzp/c5lf5Edyrqj8Tf13 n7UmTaggy9HCJVhXMHpRcnJzCKP/Tq0wTgpUJLA7fiW5xq1+CjGtYjGGcat3KGUX7AcC 3lT00o5Z+7N3dfqU8A/mYHmLAWiWVVWRvrEvE=

Hi again, On Tue, May 12, 2009 at 9:53 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> LU<MatrixXf, Algorithms::PartialPivoting> lu_partial; > > This isn't more concise than: > PartialPivotingLU<MatrixXf> lu_partial; > > and we haven't even considered the case where we're outside of > namespace Eigen and thus you'd need Eigen:: twice. Well, you are right it is not really more concise but referring to the following comment... > I'm not sure about this one: to me, it kind of suggests that LU<> is > the same class in both cases, hence in particular offers the same API, > which isn't going to be the case (partialpivoting won't have rank() > for example). ....I interpreted the class name more as an indicator of the underlying algorithm as opposed to an interface definition. Thus I thought about sticking to LU<...> in both cases since both times the core of the algorithm is a decomposition of the input matrix into a lower and upper-triangular matrix. For me the pivoting is simply a numerical issue that I see as a particular implementation detail - though it is unfortunately affecting the interface of the class. In case one thinks of the class name as something strictly defining the interface than my proposal is definitely misleading. > we haven't even considered the case where we're outside of > namespace Eigen and thus you'd need Eigen:: twice. The namespace Algorithms is not really necessary - and when the second template argument is defaulted we can hope that the typical user will have no need of typing anything else but as he did so far - i.e. LU<MatrxXf>. > Just wanted to add that I don't want to sound too negative Not at all. This is exactly what I was hoping for... I think in the end it is a matter of taste and I have not yet a strong opinion towards either of the solutions. I want to stress once more that I did not mean to discuss solely the handling of the LU decomposition only - we will run into the same question when it comes to rank-revealing QR vs. standard QR (again with and without pivoting). Or in case of the Eigenvalue decomposition. There are use cases in which the user wants nothing but the Eigenvalues (e.g. for matrix condition computation) as opposed to both values and vectors - and the performance difference in that case is vast. - Hauke

**References**:**[eigen] Design for integrating different decomposition approaches***From:*Hauke Heibel

**Re: [eigen] Design for integrating different decomposition approaches***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Design for integrating different decomposition approaches** - Next by Date:
**Re: [eigen] Re: LU precision tuning** - Previous by thread:
**Re: [eigen] Design for integrating different decomposition approaches** - Next by thread:
**[eigen] cache-friendly matrix inverse**

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