On Jun 20, 2007, at 11:17 AM, Jason Grout wrote:
> [EMAIL PROTECTED] wrote: >> Hi All, >> >> I am trying to write a small class which implements symmetric >> matrices, but I'm unclear how to inherit from >> sage.matrix.matrix_dense. How can I tell what the initialization >> does, and how to properly call it? I tried looking at >> sage.matrix.matrix_integer_dense.pyx to do this, but I'm still having >> some trouble. I have included the class and errors below. Thanks! > > I'm not sure of the answer to your question, but I have a related > question. > > It seems that the subclasses of the matrices now focus on the types of > entries. Should we also subclass on the matrix structure (i.e., > DiagonalMatrix, SymmetricMatrix, etc.), or should we instead implement > these structural things as special construction functions and set an > attribute in for the matrix indicating that it has the special > property. Pyrex does not support multiple inheritance, so we can't subclass on both. Currently, I think the best way to view the matrix hierarchy is being based on how matrix data is stored. (E.g. dense, sparse, a c array of ints or mpz_t's, etc.) As I mentioned in the previous message in this thread, I think Diagonal/Symmetric/Block may live best in the hierarchy right next to dense/sparse. If one wants to implement, e.g. a symmetric integer matrix one would then subclass that. The algorithms that work on generic dense/sparse integer matrices probably wouldn't care over to the diagonal, etc. cases anyway. > Just yesterday I needed to construct a diagonal matrix from a vector > (the diagonal entries). I ended up writing my own function, but would > like to contribute it back to SAGE. Should I contribute it as a > function in MatrixSpace (like identity_matrix or zero_matrix) or > something else? diagonal_matrix would be a great method of MatrixSpace. It could take any (length n) sequence/vector/list/tuple... > This email brings up the question of if I should > instead make DiagonalMatrix the subclass of something (if so, then > what? > Since I might want a DiagonalMatrix of any one of the types of > matrices that are currently subclasses). > > To me, it seems to make the most sense to make a special construction > function for matrices that have certain properties and then set some > sort of attribute about the matrix saying it is symmetric, diagonal, > etc. Then in the general class, we can modify an algorithm based > on if > the attribute is set (to take advantage of the matrix being symmetric, > etc.) We then have all the advantages of the current type-based > subclass system (e.g., we automatically get diagonal matrices that are > optimized based on the type of entry). I think the optimizations based on shape have much more potential than those based on type, both in terms of storage and in terms of algorithms. In your case of the DiagonalMatrix, storing the entire n x n array of mpz_t entries, with all the off-diagonal ones zero, would be very inefficient, probably even more so than storing n individual elements. If it subclassed the type-specific cases, one would have to have essentially case-statements on every algorithm (as matrix_integer_dense assumes it can just reach into its mpz_t array. In the diagonal case, I would store the actual entries internally as vectors (of the right type), and implement the diagonal matrix on top of this (mult -> pairwise mult, add -> add, etc.) - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
