2008/7/16 Mike Hansen <[EMAIL PROTECTED]>: > > Hi Arnaud, > >>On Wed, Jul 16, 2008 at 4:13 PM, Arnaud Bergeron <[EMAIL PROTECTED]> wrote: >> I am currently working on a module for combinatorics and manipulation >> of words in sage (which is much more powerful than what is already >> there). You can find our current code at >> http://sage-words.googlecode.com/ if you are interested. > > It is great to hear that you're working on this project! > >> We started out using as little as possible from the Sage library and >> then realized this was a bad idea and went the opposite direction. >> >> In this process I have encountered a problem with the Element class. >> >> 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. > > But it general, Element should not require that subclsases be "numeric". > >> Should I file a bug about this, override methods that make these >> assumptions with sensible stuff for my case or add ugly hacks to allow >> _parent(0). > > I would definitely just override that method.
That's what I'll do. > Also, I have a few more general comments. It seems that > sage.combinat.words would be a more appropriate place for this module. Since we have big plans in terms of functionality for this module we thought it would be better for it to have its own module under sage. But this could be a more sensible place since we intend to incorporate the already existing functionality in our code. I'll have to discuss of this with the rest of the team. > Also, would you mind if we included the code as optional on our > sage-combinat patch server? I could update it every official release > or more often depending on what you think would be better. We kind-of thought about developing the code to a stable and fleshed out state and then adding it to Sage (or sage-combinat if this is the place it should go). Then we would switch devlopement to work on the sage version directly. I wouldn't mind and it could even attract people to help us, but warn people not to depend on anything from that part until we get to release 1.0. Until then any and all API can be revised and changed for the most trivial of reasons. Also, and this is a call to everybody, if you have suggestions or comments about the code, you are welcome to tell us. Especially if it concerns the way to use sage objects. Arnaud > --Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
