[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]

*To*: eigen@xxxxxxxxxxxxxxxxxxx
*Subject*: Re: [eigen] solve API
*From*: Manoj Rajagopalan <rmanoj@xxxxxxxxx>
*Date*: Mon, 28 Jun 2010 18:59:20 -0400
*Organization*: EECS Dept., University of Michigan, Ann Arbor, MI, USA

> > By the way, thinking once again about your argument regarding generic
> > 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.
>
> yeah ! someone on my side :)
>
> gael
Based on the recent discussion here is my vote for various points:
1. a common inverse() is nice and should method revert to pseudo-inverse for
non-square and rank-deficient square matrices (for .svd() and related,
not .lu() of course),
2. indicating this in the documentation would nice and something a
mathematically advanced newbie would in fact expect - the pseudoinverse part
(which is an advanced concept) can be clarified with an explanation that for
underdetermined systems, the solution is in the minimum norm sense and for
overdetermined systems, the solution is in the least-squares sense (which is
also the minimum norm sense) as in LAPACK. I believe there is more than one
definition for the pseudo-inverse. Are we referring to the Moore-Penrose
definition?
3. Co-existence of inverse() and pseudoinverse() methods is confusing.
-- Manoj