Hi Robert, >> Also, this seems like a > >> lot of busywork--we should be able to automatically generate these > >> classes for any matrix type when nrows == ncols. But this is exactly > >> what the category framework gives you (though it could have done so > >> with a more sophisticated getattr rather than dynamically-constructed > >> types). > > > > But how would the category framework automatically construct a class for > > square integer dense matrices, for example? It would still have to know > > where to get the specialised determinant function from. > > That's what it does now, by multiple inheritance. It does not provide > specialized implementations, only generic ones. >
The second sentence of your answer contradicts the first one. We have a function Matrix_integer_dense.determinant() which only makes sense for matrices that (1) live over the integers and (2) are square (let's ignore the dense/sparse distinction). This is not a generic implementation and the category framework can't know about this function if it only has the classes of matrices over ZZ (without the determinant) and the class of square matrices. So maybe this should be solved by redirection, as you suggested: Matrix_integer_dense should have a method _determinant() (which raises an error if applied to a non-square matrix) and SquareMatrix should have determinant() which just calls self._determinant(). >> The primary advantage of RingElement vs Rings().ElementMethods is that > >> one can place cdef methods on the former, in particular to provide > >> fast paths for arithmetic and the coercion system (including its > >> special relationship to ModuleElement). Ideally nothing > >> category-specific should go here (though there should be a big comment > >> at the top that Rings().ElementMethods is a common parent for all > >> RingElements) and actual ring element implementations could descend > >> from RingElement or not as needed/as the implementation allows. In > >> fact, there is very little in RingElement that's not about arithmetic > >> and the coercion model, it could probably be all moved out (with a > >> clear reference in the docstring about Rings().ElementMethods, and in > >> the Element class as well). In particular, the mostly-vacuous > >> hierarchy and deceptive is_X methods starting at > >> > >> > https://github.com/sagemath/sage/blob/8118b2b39e3a129a5a6186fdc9917940f92b87a6/src/sage/structure/element.pyx#L2767 > > >> should probably be stripped out. > > > > > > At least for the is_X methods that just use isinstance, I agree that > they > > should go away; I am not so sure about the XElement hierarchy. > > What value does it provide? > ("I am not so sure" was meant literally, not as a strong statement of support for XElement.) It is true that some of the classes (like AlgebraElement) are largely vacuous, but as I said in another message in this thread, EuclideanDomainElement does seem the right place to put the gcd methods for Euclidean domains, especially since it is a Cython class. Similarly for the other methods of EuclideanDomainElement and FieldElement. On the other hand, if we want to use it as a parent class in multiple inheritance (i.e. absorb it into the current EuclideanDomains.ElementMethods or my proposed EuclideanDomains.Object.Element), then maybe the speed of Cython should sacrificed for the flexibility of Python. I don't know which of the two has more advantages. Peter -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
