Re: [eigen] Design for integrating different decomposition approaches

[ Thread Index | Date Index | More Archives ]


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

> 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).


Mail converted by MHonArc 2.6.19+