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: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 12 May 2009 21:53:11 +0200
- 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=mKh97pPg6dO6bN2D+JyWBiPJqmnmPo0tOitzpi3tf18=; b=BX1ShHG0wTx8bVJe7u3zijFBZj7tdR9wWjxM5X8AI0axq9JYO1GzWCbqcCPOJUur6U K7Bcn2iO178llz/5zbZTAlF7mTMgKgQGo6ydlap5gk/oZpRdXUn364LrpN6YcVp5Qoh/ CuVxbQ0aPcLH9XvwhsWrjD0x9HsS3qVov06ow=
- 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=aUj6RZuxzT1SGNsKNE2S+kL1kUlGX/HpGDPb/YX/oNHZ2pXNDjUmzH64G4gaQmImxX 4Arl+3XqpM3MpgE98BUdUZGXUqdU5C/9PEr7nepiFKvgqo8RdNji7Vlb05CtKX/x9C80 Riok25xfdCseoY1o0wGi/s12zTclLuYTShJTE=
Hi,
Thanks for your ideas,
2009/5/12, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> You could simply add a method in which you chose the type of
> pivoting. This is probably not the best way to do it since the LU
> interface might change or become invalid depending on the underlying
> algorithm. What do you want for instance with two permutation
> matrices, when only partial pivoting is performed?
Yep, so indeed, at least at the level of implementation, LU and
partial-pivoting-LU are two separate classes.
> What if you could write
>
> LU<MatrixXf> lu_full;
>
> and have the well known Eigen interface of the LU decomposition
> available but on top you could write as well
>
> 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.
Actually I was considering naming the partial pivoting LU just
"FastLU", what's your opinion? The idea is that it's faster but
assumes you know what you are doing (it's only valid, basically, for
invertible square matrices, as I wasn't going to bother about the
rectangular case here which will only work either for m>=n or m<=n but
not both).
I'm also a bit reluctant about us taking the habit of exposing
algorithm names as part of the API. Here it makes sense because they
are really different decompositions with different APIs but in other
cases, if the APIs are identical, better keep the choice of algorithm
a private thing so we're free to switch to a better algorithm in the
future.
> Both cases were using the same concise naming and it were clear to the
> user that both times she/he were dealing with an LU decomposition
> while offering the correct interface.
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).
Cheers,
Benoit