On Wed, Sep 18, 2013 at 2:11 PM, Peter Bruin <pjbr...@gmail.com> wrote: > Hi Simon, > > We seem to be talking past each other, I'm afraid. I could reply > point-by-point to what you wrote, I think it is more productive to emphasise > the question that I would really like to see answered: > > I am looking for a concrete example demonstrating why categories ought to > have ElementMethods. (clarification: as opposed to an example showing how > ElementMethods is implemented or how it can be used.) > > Here is what kind of example I have in mind: a realistic computation where > the user, in order to solve his problem, is led to a situation where all of > the following Sage objects exist, and where, most importantly, the last > condition holds: > > - C: instance of Category whose ElementMethods contains a non-trivial method > m > - P: instance of Parent that is an object in the category C (or, if > necessary, multiple P_1, ..., P_n in the same C) > - e: instance of P.element_class that is an element of P (or, if necessary, > multiple e_i in the various P_j) > - x: the result of a computation involving e (or the e_i) for which it was > necessary to invoke C.ElementMethods.m > - in a hypothetical version of Sage in which the method m is in a subclass > of Element, it would have been impossible, or at least much harder, for the > user to obtain x via a similar approach where e is an instance (or the e_i > are instances of) of this subclass (either statically or dynamically). > > Even after studying several of the ElementMethods classes in > sage/categories, I cannot think of such an example. (Since square matrices > and polynomial factorisation came up in this discussion: I did think whether > these gave rise to such an example). I fully admit that this could be > because of a lack of creativity or experience with the category framework. > I am also open to any other kind of example that will convince me that there > is no good alternative to ElementMethods that is based on putting the > methods in the correct Element classes. What is important is that I am > looking for realistic and completely concrete examples. > > If someone can give me an example, then my plan is to look especially > critically at the last condition and try to show that it using the > alternative approach would in fact be equally natural for the user in a > hypothetical version of Sage as above. (By this hypothetical version, I > mean one that chiefly differs from the actual Sage with respect to the > general implementation of providing elements with methods, i.e. is not > tailored specifically to the specific example in question, of course.) > > For clarity, let me finally compress my motivation into a caricature (and do > please view this as just a caricature): > - I have the impression that there are good conceptual (or aesthetic, if you > want) reasons to get rid of the attribute ElementMethods in Sage categories; > - I can think of a promising alternative approach that would get rid of this > attribute; > - before wasting too much time, I want to check if my impression above > really isn't completely idiotic, and I am trying to be as explicit as > possible about what kind of example would make me change my opinion.
Here's a concrete example: where should the generic implementation for Euclid's operation live for computing e.[x]gcd(e)? It seems that it makes the most sense to place this in the category rather than the (many) element implementations (unless, of course, there are compelling performance reasons). If I didn't understand your last point, clarify why this is not satisfied. -- 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.
