Are complex numbers ordered?

[Bruce Westbury]

This was unexpected

{{{

sage: CC(I) > CC(0)
True
sage: CC(-I) > CC(0)
False
}}}

Are these the intended results?

[Vincent Delecroix]

Complex numbers are ordered lexicographically (first by real part
and then imaginary part). I agree that it is not completely natural,
but having a total ordering is very useful when programming.

[TB]

This seems to be the case:
https://git.sagemath.org/sage.git/tree/src/sage/rings/complex_number.pyx#n1176
https://git.sagemath.org/sage.git/tree/src/sage/rings/complex_double.pyx#n807

The latter even says: "We order the complex numbers in dictionary order
by real parts then imaginary parts.

This order, of course, does not respect the field structure, though it
agrees with the usual order on the real numbers."

The _cmp_ method does not appear in
https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_double.html
and makes finding this fact harder for most users (in most cases _cmp_
and other _methods_ would make the docs harder to read). You can open a
ticket with how you suggest to fix this, even if just for the docs.

Python of course raises TypeError for any of:
sage: 1jr > 0r
sage: complex(I) > 0

Regards,
TB

> --
> 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+...@googlegroups.com
> <mailto:sage-devel+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/eac3dd75-14aa-4aa0-a42f-9e6f6381d34b%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/eac3dd75-14aa-4aa0-a42f-9e6f6381d34b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nils Bruin]

On Wednesday, May 20, 2020 at 3:42:57 PM UTC-7, mathzeta2 wrote:

This seems to be the case:
https://git.sagemath.org/sage.git/tree/src/sage/rings/complex_number.pyx#n1176
https://git.sagemath.org/sage.git/tree/src/sage/rings/complex_double.pyx#n807

The latter even says: "We order the complex numbers in dictionary order
by real parts then imaginary parts.

This is a painful legacy from python's early approach of "everything should be ordered", that sage at that time sort-of adopted. With complex numbers, python (even py2) quickly came to its senses and in Python3, objects are usually not ordered unless it intrinsically makes sense. Sage is now still stuck with the flawed design of the past. It would be nice to deprecate that behaviour now that we're released from python2.

[Benjamin Matschke]

One additional problem with the order is that it is not numerically stable.

An example where it is currently used in sage is
NumberField.embeddings()-function, the roots of the defining
polynomial are sorted this way. Due to the possible numerical
instability, it is not clear that the order of the returned embeddings
will not change with different precisions.

> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/24d36ef4-5fa7-49cd-8188-3f6bb8c95d36%40googlegroups.com.

[Michael Orlitzky]

On 5/20/20 6:42 PM, TB wrote:
>
> The _cmp_ method does not appear in
> https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_double.html
> and makes finding this fact harder for most users (in most cases _cmp_
> and other _methods_ would make the docs harder to read). You can open a
> ticket with how you suggest to fix this, even if just for the docs.

See also: https://trac.sagemath.org/ticket/14088

[Bruce Westbury]

Thank you for the replies.

It seems to me, from reading the replies, that, although this order is not natural from a mathematical point of view, there are programming reasons for it.

I am not in a position to assess these reasons but the fact that this comparison has been dropped in Python 3 suggests they are surmountable.

There is therefore a case for deprecating this (and similar) orders. However deprecating means the feature will be removed so this would require

alternatives. I have done a grep search on sage/src for_cmp_, __cmp__ and __richcmp__ and there seemed to only a few places where these are used.

I personally do not have the experience to pursue this.

An alternative would be to expand the category framework. The only categories for orderings I can see are OrderedMonoids, PartiallyOrderedMonoids.

We could also have (Partially)OrderedRings. I would consider opening a ticket for this but I would like to know if there is support for this

(both moral and practical). I suspect I am being naive about what is involved here.

Independently of these, there is an indisputable case for the thankless task of improving the documentation.