Re: [eigen] Design for integrating different decomposition approaches

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Just wanted to add that I don't want to sound too negative, we might
well end up doing as you propose, I just want to throw the other side
of the argument into the balance!
Benoit

2009/5/12, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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
>