Dag Sverre Seljebotn wrote:
_On Fri, 2010-01-08 at 00:03 -0700, Jason Grout wrote:
Dag Sverre Seljebotn wrote:
Hi Jason Grout (and others),

we started something on IRC last night which I really wanted to finish, since you mentioned that you might pick up work again on dense RDF/CDF matrices at some point.

It's likely that that point won't be very soon (i.e., before summer), but I did plan on fixing the solve_left bug at the Sage Days in a week.

I am pretty interested in a general framework for organizing the matrix code so that matrices are intuitive and powerful. It seems that we have two orthogonal criteria for structuring the matrix classes:

  (1) By matrix structure

  (2) By matrix element datatype

Right now, the classes are arranged first by sparse/dense, then by matrix element datatype. However, in a lot of cases, it is very valuable to know and store a representation of the matrix that takes advantage of the structure. How do we deal with both pieces of information (structure and element datatype) without the explosion of all possible combinations in the actual code?

My final opinion for now is to at least change the top like this:

- matrix
  [- non-numeric - optional]
     - sparse
     - dense
  - numeric
     - dense numeric
     - sparse numeric

(There's nothing of value for numerics in Matrix_sparse or Matrix_dense,
the numerical matrices might as well inherit directly from Matrix.)

This is mainly because of docstrings -- I think it makes sense to have
"context sensitive docs". If you have an RDF matrix you don't want an
example in left_solve on Qp(5), and if you have a matrix on Qp(5) you
probably care less about iterative refinement and decomposition
selection.

I'm becoming more and more convinced of this -- dense and sparse numerical matrices can essentially share the code for solve_right, and just provide different implementations of QR, LU and so on. (Provided that e.g. LU returns matrices that will do triangular solves, which is a stated goal.) That way, The algorithm for iteratively refined solve through LU decompositions don't have to be reimplemented for dense and sparse cases, and so on.

I've made this ticket

http://trac.sagemath.org/sage_trac/ticket/7920

and started on implementing it, but I don't know when I'll get back to it.

--
Dag Sverre
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to