Re: [eigen] solve API

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

2010/6/28 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Mon, Jun 28, 2010 at 8:30 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>  But I've never seen A^-1 B used when A isn't injective. In that
>> case, one says in plain text "let X be a solution of AX=B". There is
>> no way to write that as a formula.
>
> yes that's very true...
>
>> So I see your point in the invertible case, but I feel that there is a
>> problem in the non-invertible case. Since invertibility is a numerical
>> issue, I agree not to let it impact the API. But at least, non-square
>> matrices should be banned.
>>
>> How about this proposal:
>>  - call it solver() in the general case
>>  - add inverse() as another method that checks that the matrix is
>> square, and returns solver().
>>
>> Of course, in all decompositions that are restricted to square
>> matrices, no need for solver(), so this amounts to just your proposal:
>> inverse().
>
> my problem is that I really want a uniform API from diagonal matrix to
> SVD, including triangular and permutation. So for uniformity we should
> also add solver() (or pseudoInverse() or whatever) to
> DiagonalMatrixBase, to Permutation, etc... Having both everywhere
> makes no sense, they would always return the same thing, the only
> difference being that for QR and SVD inverse() would trigger an assert
> if the matrix is not square.
>
> Is it so bad to have: SVD::inverse() actually returns a pseudo-inverse
> with big warnings in the documentation ?
>
> We could also have a pseudoInverse() alias for QR and SVD, but keeping
> inverse() valid for rectangular matrix.

It's OK, I can live with that. Provided that it's crystal clear that
the current imperative solve() API remains available (and not
deprecated).

Benoit

>
> gael
>
>>
>> Benoit
>>
>
>
>