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. > I did read that, but it didn't quite suffice to make everything clear for > > me. Also, there were some occurrences like "TODO: example" that made me > > wonder if there would really be a natural example. > > I just checked: The string "TODO" or "todo" does not appear in the > thematic tutorial coercion_and_categories.html (title: "How to implement > new algebraic structures in Sage"). So, what have you been reading? > I read sage/categories/primer.html and sage/categories/tutorial.html, and various docstrings in sage/categories; I didn't remember the exact titles and thought you were referring to the first of these. In the meantime, I have also read coercion_and_categories.html, but I don't think the example in there can easily be made into an example of the kind I am looking for. I hope you anyone else doesn't feel like they are wasting their time in this discussion, and that at least something useful will come out of it for others who want to understand (and possibly extend or modify) the category framework. Thanks, Peter -- 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.
