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. Miller
http://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
