| 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