On Sat, Sep 21, 2013 at 8:09 AM, Peter Bruin <pjbr...@gmail.com> wrote: > 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.
Yes, but had we not provided a special one for ZZ we'd still get the generic one, which is better than nothing. > 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(). Yeah. That has disadvantages (e.g. introspection) but I can't think of a better solution off-hand (unless we do more hackery, like set determinant = _determinant manually when detecting this inheritance. If we follow this convention that could actually work, but it is more magic.) >> >> 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. There's no reason EuclideanDomains.ElementMethods can't be a Cython class, it just can't add cdef methods or members on top of whatever sibling classes it will be multiply inherited with. Most of the time the, however, the Cython implementations will be for various important specializations, and the Category one a generic Python one where there's not much to be gained by moving to Cython. In any case, I think the current elements.EuclideanDomainElement should be merged into EuclideanDomains.ElementMethods 'cause they're redundant and few things can actually descend from the former. - Robert -- 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.
