Hey Nicolas, I don't think it is feasible to make this as a change to a parent or category as we would have to change all classes in sage to support this framework. I almost feel as if poset should be a general construct for changing the default order on any set of objects, and we should strive to make it as lightweight and hidden as possible. Here's my current thoughts on how to do this:
- We have elements of a poset P be the elements of the set S, but on creation, we override their comparison operations. I foresee (small) problem with doing this. In an ideal world, I would rather the elements' parent be P, rather than S, but there are many classes that rely on calls to methods in S via the parent() method. Thus it becomes unclear that these elements came from P. Do you see anyway around this? - Have elements always be wrappers, but make it less obvious that it is a wrapper by having it perform the _latex_, _repr_, arithmetic (maybe return wrapped elements? perhaps throw an error/warning if result is not in the poset?), and any other common methods of the wrapped element. Also equality testing should be much more robust by testing against the wrapped element if the RHS is not a poset element (and not checking that they have the same parent, but just checking the wrapped elements). The more I think about it, the more I grow uncomfortable with the idea of facades. For example: sage: g = DiGraph([(0,1),(0,2)]) sage: P = Poset(g, facade=True) sage: P(1) < P(2) True so to do comparisons in the poset, you have to do sage: P.lt(1, 2) False and this seems even more troubling to me if facade is True by default, since I would expect P(1) and P(2) to be elements of the poset and be incomparable. Although I feel like the underlying problem is not facades, but instead the equality comparison method is not robust enough. Best, Travis On Thursday, November 29, 2012 2:36:05 PM UTC-8, Nicolas M. Thiery wrote: > > On Fri, Nov 23, 2012 at 06:53:56PM -0800, Travis Scrimshaw wrote: > > Hey everyone, > > I just had an idea, and maybe this is more wishful thinking, but I > feel > > like we should be able to pass a poset/lambda function(s)/class which > > contains comparison methods into a parent and have that be able to > > override the default ordering (similar to what C++ does in the STL). > > Something like this: > > sage: g = DiGraph([(0,1),(0,2)]) > > sage: p = Poset(g) > > sage: G = IntegerRingMod(3, ordering=p) > > sage: G(0) < G(1) > > True > > sage: G(0) < G(2) > > True > > sage: G(1) < G(2) > > False > > Well, maybe not that much of a wishful thinking actually! > > Define this category: > > class Blahs(Category): > def super_categories(self): return [Rings()] > class ParentMethods: > def blah(self): print "blah" > class ElementMethods: > def blih(self): print "blih" > def __lt__(self, other): > print "comparing!" > > And create the ring in this category: > > sage: G = IntegerModRing(3, category=Blahs()) > sage: g = G.an_element() > > Now you can do: > > sage: G.blah() > blah > sage: g.blih() > blih > > So in principle one could use that to provide comparison methods. Alas > this does not work completely, because there already is a comparison > method implemented in G which override that of the category: > > sage: g < g > False > > This also fails for partitions because they do not yet accept a > category parameter. > > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" <nth...@users.sf.net <javascript:>> > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/vN73A6DL1kUJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
