Re: [eigen] solve API
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] solve API
• From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
• Date: Mon, 28 Jun 2010 21:23:56 +0200

```On Mon, Jun 28, 2010 at 3:19 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> I really prefer inverse() because ...

I agree with Gael, I also prefer inverse(). Not only because it is
generic but also because

x = A.lu().solver() * b

looks a bit strange and would require template arguments for

> For rectangular matrices, inverse still make sense as the pseudo
> inverse. The weird thing is that the returned Inverse expression would
> become the left pseudo inverse or right pseudo inverse at the moment
> it is applied to a matrix:
>
> Matrix m(r,c);
>
> x = m.svd().inverse() * m; // left pseudo inverse, x = identity(c,c);
> x = m * m.svd().inverse(); // right pseudo inverse, x = identity(r,r);

This is too bad because I just wanted to propose

x = A.svd().pinv() * b

or

x = A.svd().pseudoinverse() * b

algorithms, I am not sure anymore whether I would totally agree. QR
and SVD for instance might be offering a unified ::pseudoinverse()
function (well, in that direction) because in fact, whenever the
matrix is not invertible, this is what the method return. Well, I hope
I am right with that. :) On the other hand side, we could simply agree
on the common understanding that inverse() might potentially be
returning/computing the pseudo inverse.

> meaning that:
>
> mat = svd.inverse();
>
> would be undefined (illegal), but I think that's fine.

So, you mean

mat = A.svd().inverse()

but what you say should only be true if A is not square. When A is
square, that should be possible and as I mentioned before it were
holding for QR too.

- Hauke

```

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/