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.
Yes, that's what I meant -- I certainly didn't intend for you to do all
I mentioned, just interested in how solve_left was fixed.
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?
For non-numerical purposes one could do
cdef MatrixElementAccessor elements = matrix._fast_access()
value = elements.get(i, j)
to decouple get/setitem_fast from the choice of inheritance structure --
or have one inheritance structure for matrix operations and another for
item access.
For numerical purposes get/setitem_fast is useless anyway (you don't
want polymorphic dispatch if working at single-element level), and
adding if-tests there shouldn't matter.
I believe the seperation of RDF and CDF double matrices to be a mistake
for that reason, and I did not follow that pattern for sparse matrices
(there's only one class for both RDF and CDF).
So for sparse matrices it works out like this:
matrix -> sparse -> double precision [ -> hermitian/triangular/...]
This works well without any combinatorial explosion (double precision
sparse hermitian matrix multiplication is something one might want to
specialize for anyway).
For dense numerical matrices I'd loose the real/complex distinction, it
doesn't seem like it brings any benefits.
For non-numerics I don't really care, but I'd start with the element
accessor thing above to decouple type (primarily needed in element
accessor?) from structure (needed for algorithms).
--
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
