On Nov 12, 2008, at 1:35 AM, Nicolas M. Thiery wrote:
> > Dear Mike, dear Robert B., > >> Mike: >> Maybe I'm just confused, but I'm not sure how the element >> hierarchy in >> your categories works with Cython. In particular, what do you see >> the >> inheritance tree looking like for say ModuleElement since you want >> that to be in Cython so that arithmetic with them can be fast. > > Here is what I have in mind; it's good that we discuss this to check > this is indeed feasible. > > Most of free modules won't use ModuleElement straight away, but rather > some subclass (with extra operations). Then, for the inheritance tree, > I see two options (the only difference is whether or not ModuleElement > "inherits" from ModuleWithBasis.element_class): > > (I) > ... ... ... ... > | | / | > ... ModuleWithBasis.element_class > Algebra.element_class > | | / > ModuleElement AlgebraWithBasis.element_class > | / > MyAlgebraElement > > > (II) > ... ... ... ... > | | / | > ... ModuleWithBasis.element_class > Algebra.element_class > | / | / > ModuleElement AlgebraWithBasis.element_class > | / > MyAlgebraElement > > > With (I), ModuleElement barely defines a data structure + a repository > of some fast operations, but without mathematical structure; it cannot > really be used by itself. Of course some of the fast operations (e.g. that addition exists) are inherent what the "mathematical structure" or a module element is. > Some of the standard ModuleWithBasis > operations may very well be only defined generically in > ModuleWithBasis.element_class without fast cython specialization in > ModuleElement. I like this. Currently there is a (mostly empty) sequence of classes in Element.py that don't do anything, and on the other hand something like Polynomial (which all univariate polynomials inherit from) can only inherit from one of them (because its inheritance is decided at compile time). Cleaning up and detaching things from the "straight- line" inheritance we have now will be very good. > With (II), ModuleElement is really a ModuleWithBasis. This is > mathematically nicer, and, in the simple cases, allows for using > ModuleElement directly without deriving a subclass. But this requires > some partial multiple inheritance support for Cython classes of the > form: in m.a, if a is an attribute of m or is defined by a super class > in the linear hierarchy above ModuleElement, then do the usual > thing. Otherwise, resort to a "library level" getattribute lookup > through the full hierarchy. I don't know how feasible this is. This is essentially what my patch did (though with name mangling rather than looking it up on a separate set of classes). Other non- name-mangling ways of doing this could be used as well, as long as things don't have to be kept in sync manually. One caveat is that a (non-static) method can't be bound to an element that is not an instance of the method's class (or one gets the the good old "unbound method foo() must be called with A instance as first argument" error). - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
