On Jul 18, 2008, at 6:31 AM, Arnaud Bergeron wrote: > 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.
Just for the record, __nonzero__ is a Python special method, nothing to do with Parents/Elements. >> 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. Yes, this needs to be documented better, and is in a large state of flux. I have been spending time writing better documentation for the coercion model as part of the rewrite. > 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. Where do you want to coerce to? To keep coercion consistency and complexity reasonable Parents only specify coercions to them, rather than from them. The exceptions to this are (in the future) a single embedding, and a handful of special methods for the basic types (like _integer_, _rational_, ...) - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
