2008/7/17 Kurt <[EMAIL PROTECTED]>: > > On Jul 16, 2:39 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote: > >> > I have a class which represents the set of words over an alphabet (but >> > is not a Monoïd since it also contains infinite words) and another >> > class which represents a word. These classes have a natural >> > Parent/Element relationship and I tried to use these classes from Sage >> > as superclasses. >> > But I am encountering various problems due to the implicit assumption >> > that the Elements are always sort of numeric. As an example >> > Element.__nonzero__() tries to call the parent with 0 to compare >> > against the 0 element. But in my case it does not makes sense to >> > create a word from that. >> >> > So I am stuck. We already have a working parent/element relationship, >> > but since it is not the Sage one it does not participate in coercions >> > and we can't use Sage morphisms. >> >> The Element.__nonzero__ is just a sensible default that should be >> overridden if needed by subclasses of Element. The __nonzero__ method >> gets called if you have an object a and you do "if a:". See the >> example below: >> >> sage: class Foo(object): >> ....: def __nonzero__(self): >> ....: return True >> ....: >> sage: a = Foo() >> sage: if a: >> ....: print "a is 'nonzero'" >> ....: >> a is 'nonzero' >> >> So, you should decide how you want your words to behave with respect to this. >> > > Just to throw in my two cents, the fact that the class has a member > function __nonzero__() suggests that the class is intended for > objects supporting some sort of binary operation. Certainly one is > not forced to use such a class in this way, but that is the > intention. And given that we want to be able to construct things like > combinatorial algebras from other combinatorial objects, it makes > sense that a class of combinatorial objects support designating a zero > (identity) element for some binary operation and a way of testing > whether a given instance of the class is this zero element. Words are > certainly one such class of combinatorial object. And while there are > many kinds of binary operations one might define on words, for a great > many of such operations that occur naturally, the empty word turns out > to be the identity element. So I think a more reasonable default for > the word class would be that the integer zero is coerced to the empty > word, and __nonzero_(w) would return True iff w is the empty word, > even if the entire set of words does not form a monoid.
That is exactly the behaviour I wanted except the coercion of 0. It really does not make any sense the way our code is designed to have 0 coerce to the empty word. Plus it would be a unique special case possibly confusing the coercion machinery. So according to the recommendations earlier I've overridden the method to do that. > But I think this discussion does bring up the question of how such > structures are factored within the overall combinatorics module. It > is reasonable to expect to be able to design a class X for some kind > of combinatorial object (words, trees, graphs, matroids, etc) without > necessarily declaring any sort of binary operation, and without regard > to higher future uses, such as forming the basis of an algebra. One > would like subsequently to be able to form an algebra or coalgebra or > other type of higher structure from the elements of type X, making use > of the X code, but without burdening the class definition of X by > adding these other notions necessary for the higher structure. It is > at the point that one forms the higher structure that one needs to > worry about what the binary operations are and what is are the > identity elements, if any, of these operations. I have not examined > the existing Sage class structure enough to know how cleanly these > concerns are separated, but it sounds like the kind of concern that > Arnaud is driving at. There are also costs as well as benefits of > separating these concerns in the implementation, so it is the sort of > think that deserves a hard look (sober evaluation) before dashing off > in any particular direction. These are probably valid concerns, but that's not what I had in mind with my message. It really is more or less a call for documentation of the basics of implementing a Parent or Element class. And now I am encountering another problem with coercion. Basically the coercion system refuses to coerce anything from my class. I think it's because I am missing an essential method for coercion because I didn't implement anything for this. Looking at the various methods that seem related to coercion I can't get an idea of what to implement. Arnaud --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
