On Fri, Oct 18, 2013 at 10:55 AM, Nicolas M. Thiery <nicolas.thi...@u-psud.fr> wrote: > Hi all, > > Shoot, I missed this thread one month ago ... My view point in two > sentences: > > In theory I would want to get rid of all the ModuleElement / > RingElement / ... hierarchy of classes. The rationale is that this > hardcoded hierarchy just does not scale: it's impossible to model but > very few categories, in particular due to single inheritance. That's > precisely because of this scaling barrier that we introduced the > category mechanism [1]. And indeed, when I write my own parents, I > almost never derive from the *Element classes.
+1 > However, at this point in time, one cannot yet cythonize methods in > categories. Thus, for the time being, we still recourse to this > hierarchy of cython classes for those critical parents where > arithmetic is so cheap (e.g. finite fields, ...) that we can't afford > the overhead of going through a Python method call. It's a little more subtle than that. The underlying restriction is that one can't have multiple inheritance of classes whose C members (including cdef methods) are incompatible. This includes the arithmetic methods, but I think those could all be moved up to the root Element class and by default return NotImplemented (just as everything has a default __add__). The concrete elements could be in Cython (minus a complicated inheritance) and methods in ElementMethods can also be implemented in Cython (though they would still suffer from Python lookup and Python calling convention overhead). On that note, I have been looking at exposing C function pointers at runtime, which would avoid the Python calling overhead and allow passing of primitive types without the need for compile-time declarations or fixed layouts. > In short, the plan I have always had in my head is to: > > - move all non time critical methods from the *Element hierarchy to categories > - make have all non time critical parents not use the *Element hierarchy > - explore the cythonization of category methods > - explore good idioms to do more type checking > - hopefully someday deprecate the *Element hierarchy and get rid of it > altogether +1 > [1] Hopefully the new primer coming with #10963 will make this point clear! > > -- > Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> > http://Nicolas.Thiery.name/ > > -- > 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. -- 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.
