On Nov 9, 2008, at 7:31 AM, Nicolas M. Thiery wrote: > Dear Sage developers, > >> On Tue, Aug 19, 2008 at 8:14 PM, Bill Page >> <[EMAIL PROTECTED]> wrote: >>>> The Sage concept of 'parent' is an attempt to capture similar >>>> generic >>>> relationships that are represented by categories in Axiom, but I do >>>> not like the fact that this concept needs to be added on to Sage >>>> rather than being supported by some more fundamental feature of >>>> Python, e.g. Python meta-types. > >> William Stein: >> Unlike you, I personally like that parent is not a fundamental >> feature of Python, but a "design pattern" that can be implemented on >> top of Python. That means one can directly use the same idea in >> C/C++/etc. code. > > Let me reuse this thread for further discussions about categories. > > To start with: a disclaimer. I am a complete practitioner > here. Language design is not at all my specialty. But I do have a bit > of experience using and designing categories in MuPAD (MuPAD-Combinat > adds about 60 categories to the standard MuPAD hierarchy) as a design > pattern for organizing and factoring out generic code. > > My feeling is that we need both concepts of parents *and* of > categories (more rant about this upon request). And I like the idea of > having them as design pattern not tighten too much to the language. In > particular, this means that we can progressively improve the design > pattern to increase its expressiveness in our context.
+1 > We used that a > lot in MuPAD. Of course, in the long run, further and deeper support > from the language could help improve the safety. > > With Florent, Mike, and Robert we spent some time discussing about > categories for Sage. I am now implementing a prototype (available in > sage-combinat), whose design differs slightly from that of: > > http://trac.sagemath.org/sage_trac/ticket/4301 > > The idea is to let a category define generic code for parents and > elements through standard class inheritance (with some class surgery > done automatically behind the scene). It's a bit more tricky to setup > internally, but avoids messing around with getattr (that is in > practice introducing another technical way for doing multiple > inheritance; I am not speaking of cython object there, which probably > will need some getattr tricks since standard multiple inheritance does > not work). > > The current design should leave the door open for those who will want > to do category theory (i.e. calculations on the categories > themselves), rather than using them to organize generic code which is > my own main goal. This is the "categories are bags of methods which are valid on particular parents/elements" philosophy, which I agree is very useful. One of the main goals is to be able to implement a ring R and, by virtue of declaring it to belong to the category of Euclidean Domains, a working gcd method would get attached to all the elements of R. There are, of course, other uses for Categories but letting them be full-featured objects allows for further flexibility. > See the attached files for some details. If I understand your code correctly, what you're proposing is that to declare an Parent/Element to be a member of a category, one creates the category and then dynamically creates classes at runtime that need to be inherited from. Using QQ[x] as an example, I would create the category C = JoinCategory(EuclideanRings(), Algebras(QQ)) and then inherit from the dynamically created C.parent_class() and C.element_class(). Actually, if I wanted to sit down and write my super-optimized QQ[x] (say, by wrapping FLINT) I'm not even sure how I'd go about doing that. It's also unclear how this would fit into the coercion model (where the cdef classes Element and Parent use on c-level methods and attributes for speed). But you do avoid needing to implement a __getattr__ method. > My plan, with the help of Teresa, is to setup soon a full category > hierarchy (with most categories being dummy for the moment), as we had > discussed with Robert and others during Sage days 7 (most inspiration > coming from Axiom/MuPAD). Before we proceed, we have some questions: > > - Has anyone done work in this direction lately? No. There's been times I've wanted to use it for stuff, but the patch you referred to is still sitting un-refereed (as it probably should while we hammer out our exact approach to these things). > - Did anyone keep a list or graph of the desired categories from > sage days 7? > For reference, the hierarchy for MuPAD-Combinat is available there: > http://mupad-combinat.sourceforge.net/Papers/Categories.pdf I thought someone took a photo of it, but I don't know who. > - Are the Sage categories currently used for anything but documenting > and testing the mathematical properties of parents? Not currently, which is unfortunate. I'm glad you're taking up the banner to change this :). > - In particular, does anything depend on the current category > hierarchy, as defined at the end of categories/category_types.py, > or should we feel free to reorganize / extend it in any > mathematically meaningful way? Yes, though the current coercion system does use morphsims (which, in turn depends on the creation of homsets). > - Do we want to stick to the (possibly questionable) Axiom/MuPAD > convention to distinguish between monoids (or groups/...) written > additively or multiplicatively: > > - AbelianGroup, AbelianMonoid, ...: structure for the + > operation > - Monoid, Group, CommutativeGroup, ...: structure for the * > operation > > With this convention, a Ring is both an AbelianGroup and a Monoid > > Alternatively, one could use the more verbose AdditiveMonoid > w.r.t. MultiplicativeMonoid; other suggestions are welcome. > > Part of the question is whether we will ever want to have a > category for non abelian monoids written additively (I would > personnaly frown upon this, as much as I dislike using + for > concatenation of lists and strings; but that might be just me). We currently do that in Sage too. Yes, I think we should, if just for the ease of writing generic algorithms that can use inline arithmatic rather than having to get the operation as a function and call z = op (x,y) everywhere. I implemented http://trac.sagemath.org/sage_trac/ticket/3999 which mitigates the separation. I think a similar thing could be easily written for a the parent-as-element class to cover your concern about parents at different levels (e.g. monoids of monoids). I actually think this distinction is good, as the behavior of an object viewed as a parent may be different than that same object viewed as an element (e.g. "order" has different meanings in the two contexts, and I would expect something like "trace" to return a value for elements and a function for parents). - 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 -~----------~----~----~----~------~----~------~--~---
