I strongly agree with Nils. For me having a well-defined ordering (in the senseof sorting) of number field elements is very important and must not change for "hidden" reasons such as existence of a real embedding. You can almost canonically sort algebraic numbers (regardless of which field they are thoujght of as belonging to) using their minimal polynomial (suitably scaled,say as a primitive integer poly with positive leading coefficient) but this leaves the difficulty of distinguishing Galois conjugates.
John On 23 October 2014 21:51, Nils Bruin <[email protected]> wrote: > 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. -- 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.
