#20287: Implement the Moore–Penrose matrix pseudoinverse
-------------------------------------+-------------------------------------
       Reporter:  jdemeyer           |        Owner:
           Type:  enhancement        |       Status:  positive_review
       Priority:  major              |    Milestone:  sage-7.2
      Component:  linear algebra     |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Jeroen Demeyer     |    Reviewers:  Frédéric Chapoton
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/jdemeyer/pseudoinverse           |  3a3f5521eb8ced6c64a329918ac3544633286e89
   Dependencies:  #20286             |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by mjo):

 Replying to [comment:12 jdemeyer]:
 >
 > I don't think that there are cases where the is a better choice than the
 default one. However, there might be cases where there is no suitable
 algorithm at all.

 Then why offer the choice? I ask because, if you remove the `algorithm`
 parameter, it looks like a matrix superclass method is trying to figure
 out what to do by a "what subclass am I" heuristic. In that case, if the
 matrix class hierarchy is good enough, it might make more sense to move
 the subclass-specific behavior into subclass methods.

 For example, the default `Matrix` would implement the "exact" or
 "exactconj" algorithms. (Is there a situation where "exactconj" does the
 wrong thing on a real matrix?) In `Matrix_real_double_dense` and
 `Matrix_complex_double_dense`, you would call numpy. In
 `Matrix_generic_dense`, you would do the precision check and either call
 numpy or raise an error. Et cetera. On the other hand, if the matrix
 hierarchy would make you copy/paste the same implementation around, forget
 I said anything.

 Later on if we get an SVD that works for RR/CC, we can just add it to
 override the naive algorithm in those subclasses. With `algorithm` in the
 function signature, we have to worry about breaking the user interface
 with those changes.

--
Ticket URL: <http://trac.sagemath.org/ticket/20287#comment:15>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to