On Thursday, October 23, 2014 12:26:53 PM UTC-7, David Roe wrote: > > I disagree, since this approach will yield a < b and b < a both False most > of the time. Moreover, it will only work if K is either totally real or > CM. We should have two codepaths, one for testing equality (which is fast > and doesn't need to use approximation), one for testing inequality in the > presence of an embedding (which must use the embedding) and one for testing > inequality without an embedding. I'm not sure what the best approach would > be in this last case; perhaps lexicographic based on the power basis? >
I think it's dangerous to have the behaviour of an operation on an object depend on a subtle setting on the object (e.g., with a little bit of work I think people can even install an embedding on a number field once it's been created). The problem here being that "<" on a number field with a real embedding has a well-defined mathematical meaning, whereas if we define "<" on a number field without an embedding, it's going to be necessarily arbitrary. If sage silently switches between the two depending on the presence of a blessed real embedding you're inviting fragile code in two ways: - If people decide to do surgery and install/modify an embedding of a number field, they're going to get unexpectedly different results [to some extent this is their own error and I don't think we can avoid this] - If people use code that was designed to use a number field with a real embedding installed, but use it with a field that has no such embedding installed they'll silently get ill-defined results rather than an error. The latter point can be solved by having a predicate "has_a_mathematically_meaningful_ordering" which then people should check whenever they need to use it, but I think that's dangerous. It's a little silly that people have read python's requirements as "any two objects need to have "<" defined on them because "sorted" should always work. We already know that we won't get consistent results in sage anyway if we try to implement this (because there are domains where we absolutely have to follow a mathematically meaningful ordering) and in any case, this design decision has been abandoned in python 3 anyway: >>> L=[complex(1,2),complex(3,4)] >>> sorted(L) TypeError: unorderable types: complex() < complex() Since specifying a key is so dead simple anyway, we should put the onus on the user of sort to ensure that the sort command will succeed: >>> sorted(L,key=str) [(1+2j), (3+4j)] and do away with all the arbitrary ordering implementations and deal with the errors instead. Raised errors are much preferrable over some arbitrary results, in my opinion. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
