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
