On Friday, February 5, 2016 at 4:05:22 AM UTC-8, John Cremona wrote:
>
> Understood. I thought that a total order was implemented for number
> field elements, but looking in the code I could not even find the
> relevant _cmp_ function!
>
It's there, but indeed it doesn't implement a total order:
sage: k.<a>=NumberField(x^3+x+1)
sage: a._cmp_??
Source:
cpdef int _cmp_(left, sage.structure.element.Element right) except -2:
cdef NumberFieldElement _right = right
return not (ZZX_equal(left.__numerator, _right.__numerator) and
ZZ_equal(left.__denominator, _right.__denominator))
so it only tests if equality holds (for quadratic fields, the situation is
different. There seems to be a lex order there (wrt whatever basis is used).
The real problem here is of course that we're getting inconsistent results
instead of an error. With an error you would have known immediately to use
an appropriate "key".
"_richcmp_" does have enough information to throw an error, but it prefers
to punt to _cmp_. I think we need to move to a "_richcmp_" only environment
eventually. In order to so gradually perhaps we can do something like:
1) rewrite _richcmp_ to try the "<,=,>" etc. in preference to calling _cmp_
2) devise a way to allow objects to indicate that the result from "<,=,>"
is authoritative and that _cmp_ should not be tried
3) start removing _cmp_ methods
[I'm not sure 2 is necessary or will make a real difference.
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
