Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a more reasonable sorting of complex numbers #2033

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

edgarcosta
Copy link
Member

In the current sorting, we have z < conjugate(z) and conjugate(z) < z.

I propose sorting on the real part; if they overlap, use the imaginary part.

Note that in the library, _acb_vec_sort_pretty is used to sort polynomials' roots, which are multisets of non-overlapping balls.
Therefore, we will obtain a predictable and stable sorting with the new comparison function.

PS: this will break some tests at Sagemath, as the roots will now come in a different order, but this is how I got into this rabbit hole.

@edgarcosta
Copy link
Member Author

@fredrik-johansson, I might have some tests to fix, but before I do that, please let me know if you agree with the change.

@fredrik-johansson
Copy link
Collaborator

I agree the comparison function is buggy. However...

Therefore, we will obtain a predictable and stable sorting with the new comparison function.

... I don't think this is true. Even if the roots are non-overlapping, real or imaginary parts can be overlapping. No matter how one defines the comparison function, the order of non-exact balls will be essentially random in case of componentwise overlap (though one can make such cases exceedingly rare by using a more artificial comparison function, e.g. mapping a+bi -> a+bc where c is some fixed, unattractive real number).

Now, there is also some logic to the current comparison: it intended to put real roots first and then group complex conjugates. A more robust version of the idea can be found in qqbar_cmp_root_order.

It would be useful to provide both "lexicographic" and "root order" comparisons/sorts for complex numbers.

This could also be implemented using generics with the option to error when the comparisons fail.

@edgarcosta
Copy link
Member Author

I agree.
Honestly, I was thinking about this from the perspective that these roots arise from an irreducible polynomial defined over Q, as I am trying to order the embeddings of a number field into C.
In this scenario, one might have several roots with overlapping real parts $x$, but their imaginary parts will be distinguished.
I also agree that these might no longer overlap at higher precision, but while they overlap the order will not change, and it is predictable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants