Hey Peter, The first thought/example that comes to my mind is matrices. In particular, non-square matrices (of a fixed size) don't belong to the category of Rings(), so it doesn't make sense to have an is_unit() method. However it does make sense to have a __mul__ method which does matrix multiplication, and implementation-wise they (square and non-square) are fundamentally the same. What the category (ElementMethods) does is act like a dynamic base class and gives square matrices the additional ring-like methods, but without having to worry about the actual classes or having additional subclasses. IMO, much more of the methods in Element and its subclasses should be in the proper categories, but some of the reason it hasn't been done is because not everything has moved into the category framework.
Best, Travis On Friday, September 13, 2013 12:23:21 PM UTC-7, Peter Bruin wrote: > > Hello, > > A discussion was just started at http://trac.sagemath.org/ticket/15192about > the reason why categories in Sage have a class ElementMethods. In > this ticket, Julian Rüth moved the method is_unit from RingElement to > Rings().ElementMethods to fix a certain bug. I thought this wasn't the > only possible fix and wondered why the latter existed in the first place. > We thought it would be a good idea to move the discussion here. > > For now let me just quote myself out of context (see the ticket for > context): > > Parents describe relations between elements; e.g. a ring is a set whose > elements satisfy certain axioms. Categories are on a higher level; they > describe relations between objects, and it shouldn't matter too much what > the elements of these objects are, or even if the objects are sets at all. > > Whether an element is unit depends on relations satisfied *within* its > parent, not on relations between the parent and *other* parents. In other > words, the category its parent is in should not play any role. It is true > that some categories (like the category of rings) *are* in a sense > defined by relations between the *elements* of objects, but exploiting > this to influence the behaviour of elements is confusing two different > levels of abstraction, in my opinion. > > Hence, I don't see a good mathematical reason for putting methods in > Ring.ElementMethods instead of RingElement. I can see why one would want > a Category to have ObjectMethods (which are now called ParentMethods) and > perhaps MorphismMethods (which only exist in a doctest). With > ElementMethods, however, I somehow get the feeling that the authors of > the category framework are aiming for world domination! > (Last sentence is tongue-in-cheek, of course.) > > Can someone more familiar with the category framework motivate the reason > for ElementMethods? Are there methods that cannot or should not be put in > the relevant element classes (such as RingElement above)? > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
