Hi Travis, Am 2014-08-01 um 20:14 schrieb Travis Scrimshaw: > The creation of the monoid (Parent and Element) is described very well > in [1] (and got to understand the category framework a bit more). From > an object-orientated point of view, I now would inherit a class for the > invertible elements from both, the created monoid element and from > GroupElement. This class will have methods only invertible elements > have. > My question now is, how the interplay between all theses elements (and > also parents) is. In particular, when I create an invertible element > through my monoid parent, does this already give a group element or > do I > explicitly have to construct the element via the group parent? How is > this handled usually? Is there some (well written ;)) code (some > monoid/groups) in Sage, where I can see a similar thing going on? > > > How I did it for free monoids/groups whose generators are indexed by > arbitrary sets (indexed_free_*.py) and how I would suggest would be to > have a class for the monoid element, and then have the group element > inherit from the monoid element (plus whatever else seems appropriate) > and implement the inverse there.
Ok, this was/is the plan. > In implementing the multiplication, you > should be ending with something like > > | > returnself.__class__(self.parent(),data) > | Yes. > Now I would also implement _coerce_map_from_(self, P) for the group (the > parent) which returns True when P is an instance of the monoid (the > parent) > (which I did not implement for the free group...probably should > do that). Then I would have the group's _element_constructor_ handle > elements from the monoid and spits out an element of the group. Then the > coercion framework will take care of the rest. This sounds like a coercion from the monoid to the group, but IMHO should be the other way round. Each group element is also an monoid element (therefore the coercion always works). > I don't know of a specific place where this is currently for > monoids/groups. There's code scattered throughout sage for the > _coerce_map_from_ (ex. shuffle_algebra.py, symmetric_group_algebra.py in > the latest beta). Ok. I hope that helps, and feel free to cc me on the > ticket (tscrim) or ask if you have any other questions. I will (but will take some time, since there are also other things to do...) BTW: is there a reason why sage.groups.group.Group is derived from Parent and not from Monoid (Monoid_class)? > There is also a second question I have (but much more non-specific): My > elements can be seen also as functions acting on some set and the > monoid > operation corresponds to function composition. Is there a way to bring > this aspect in? (As this question is very vague, I'm happy with every > input you can provide.) > > You can implement a __call__() method to have the elements act as > functions (although you'll have the implement the function composition > and possible coercions manually). Ok. > Alternatively it might be possible for > the element to inherit from Map or Morphism, and in that case, the > coercion would be done automatically and you'll want to implement > _call_() (with only one underscore). I'd suggest trying the latter first. Yes, definitvely. :) Many thanks for your input. Daniel -- 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/d/optout.
