2008/7/18 Robert Bradshaw <[EMAIL PROTECTED]>: > > Just for the record, __nonzero__ is a Python special method, nothing > to do with Parents/Elements.
What it has to do with Elements is that the current Element class implements it. Nothing else. >>> 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_, ...) In the _mul_ method I allow concatenation of words of differing alphabet as long as all the letters of both words are in one of the alphabets. I would like to keep this behavior but the coercion mechanism refuses. I know I have to tell it either how to do it or just that it's possible but how? Maybe I should just wait for Sage 3.1 and the new model and implement that. Especially if the documentation is much better, I could figure it out. > - 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 -~----------~----~----~----~------~----~------~--~---
