Wow, I'm 100% certain I have nothing to add to this quandary, and couldn't possibly know the correct answer/choice, only supply the link to the relevant context Robert refers to:
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#ordering-comparisons Down the rabbit hole indeed. D On Aug 4, 1:23 pm, Robert Miller <r...@rlmiller.org> wrote: > Also, consider the fact that many Sage functions use "return > sorted(output)" to guarantee a consistent ordering of the output. What > you're advocating means that this wouldn't work in many cases... > > > > > > On Wed, Aug 4, 2010 at 4:16 PM, Robert Miller <r...@rlmiller.org> wrote: > > Nils, > > > So you want Sage Sets to implement "a < b" to mean "a is a subset of > > b"? I'll admit that that is reasonable, and it is a fact that it > > follows Python convention. But I think that the Python convention is > > bizarre, especially given how they implement sorting lists. I would > > also rather the sort function return an error than being undefined, > > but as far as I can tell, this "feature" is here to stay. (Actually I > > think it would be nice if sorted(L) returned a sort of L, but clearly > > that's too much to ask.) I took a look at Python 3.0 and the situation > > gets more extreme. Heterogeneous arrays are no longer sortable at all, > > and sorted() still uses "<", which is still "subset" for sets. So the > > Python devs are valuing sorting less and less and less. > > > In Sage, we have a bizarre mixture. Python sets act as above. Sage > > sets have the horrible A < B unless A = B. Subspaces of a vector > > space, however, order lexiographically, and not by inclusion. The > > reasons given being a justification for that. I have to say I disagree > > with the implicit statement I am reading in your message which is that > > "<" can only be "decidedly mathematical" if we define it to mean > > subset. Groebner bases are also decidedly mathematical, and define all > > sorts of arbitrary total orderings... > > > Maybe if I explain the use cases I have in mind you will have more > > sympathy, or maybe someone can suggest a good long term solution. Many > > graphs in algebraic graph theory have interesting vertex sets. Some > > can be collections of subsets of a certain set, or subspaces of a > > certain space, or even more crazily, sets of sets. As it is right now, > > Sage graphs allow anything hashable as vertices, with no restrictions. > > I view this as important, since graphs themselves are very flexible > > mathematical objects. For things like the adjacency matrix, having a > > consistent if arbitrary total ordering of the vertices is important. > > Now if we allow Sage objects to implement total orderings in general, > > then we can just note to avoid using Python sets as vertex sets, since > > we can't do anything about that. > > > On the other hand, if the __lt__ etc. methods implement orderings that > > aren't total orderings, sorting gets very messy. In particular, users > > will be complaining about all sorts of Sage objects falling into the > > same trap where sorted(L) returns a list which isn't consistent. (Or > > maybe I'm the only person here who cares...) > > > As a thought exercise, let's persue the partial ordering idea, fixing > > Python's frozensets as our vertices. (Frozen so that they can hash, > > Python so that we can't really change the "<" convention even if we > > wanted to.) Imagine the following situation. We want to define a > > consistent ordering on the vertices, so we use their hashes. Now, we > > come to a collision. What to do next? We need to define *some* > > consistent ordering so that operations like adjacency matrix, etc. > > give consistent, sensical answers. It is not clear to me what to do > > when we get hash collisions. > > > Furthermore, Sage graphs will vastly slow down if we implement a > > custom sorting function which tries to deal with this case by case. > > > On another angle, Python has clearly dealt with this problem > > internally, but they don't seem willing to share this with their > > users. Python sets must contain only hashable elements. This is > > because Python is using hashes to test containment and equality. I > > love this kind of stuff > > {{{ > >>>> sorted( [ frozenset([2,3]), frozenset([1,2]) ] ) > > [frozenset([2, 3]), frozenset([1, 2])] > >>>> sorted( [ frozenset([1,2]), frozenset([2,3]) ] ) > > [frozenset([1, 2]), frozenset([2, 3])] > >>>> sorted( set( [ frozenset([1,2]), frozenset([2,3]) ] ) ) > > [frozenset([1, 2]), frozenset([2, 3])] > >>>> sorted( set( [ frozenset([2,3]), frozenset([1,2]) ] ) ) > > [frozenset([1, 2]), frozenset([2, 3])] > > }}} > > > But, they don't seem to have *acutally* dealt with the problem: > > {{{ > >>>> a = frozenset([1,2]) > >>>> b = frozenset([2,3]) > >>>> c = frozenset([3,4]) > >>>> A = frozenset([a,b]) > >>>> B = frozenset([b,c]) > >>>> sorted(set([A,B])) == [A,B] > > True > >>>> sorted(set([B,A])) == [B,A] > > True > > }}} > > > So, given that we want to have graphs whose vertex sets are sets, or > > subspaces, what is to be done? I don't want to implement sorting of > > every different type of object in the graph code, I'd much rather have > > things be sane from the start. > > > -- > > Robert L. Miller > >http://www.rlmiller.org/ > > -- > Robert L. Millerhttp://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
