-
-
Notifications
You must be signed in to change notification settings - Fork 676
refuse to compare two ideals that we don't know how to compare #41040
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
base: develop
Are you sure you want to change the base?
Conversation
Documentation preview for this PR (built with commit 2c8bed3; changes) is ready! 🎉 |
def _richcmp_(self, other, op): | ||
""" | ||
Compare the generators of two ideals. | ||
Compare two ideals with respect to set inclusion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only a partial order... right? cf. how are ZZ[x,y] currently compared?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. As far as I can tell from a quick experiment, ideals of ℤ[x,y] are compared by set inclusion, while ideals of ℤ[x] are compared by generators. This patch renders the behaviour uniform in that regard. (It is possible that I missed some other rings that compare ideals in a non-mathematical way.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait, seriously.
sage: R.ideal(x) < R.ideal(y)
False
sage: R.ideal(x) > R.ideal(y)
False
which means…
sage: sorted([R.ideal(x), R.ideal(y)])
[Ideal (x) of Multivariate Polynomial Ring in x, y over Integer Ring,
Ideal (y) of Multivariate Polynomial Ring in x, y over Integer Ring]
sage: sorted([R.ideal(y), R.ideal(x)])
[Ideal (y) of Multivariate Polynomial Ring in x, y over Integer Ring,
Ideal (x) of Multivariate Polynomial Ring in x, y over Integer Ring]
at least with the previous behavior, sorting is order-invariant.
actually…
sage: sorted([frozenset({1}), frozenset({2})])
[frozenset({1}), frozenset({2})]
sage: sorted([frozenset({2}), frozenset({1})])
[frozenset({2}), frozenset({1})]
there is a precedent. Maybe it's actually fine.
sage: frozenset({frozenset({2}), frozenset({1})}) == frozenset({frozenset({1}), frozenset({2})})
True
most Python containers are hash-based instead of order-based so they're unaffected by non-total-ordering. (doctest output checker may suffer however)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Even the comparison between standard Python set
s is only partial. Related comments: #37409 (comment), #35546 (comment).
some other |
As far as I can tell, in this context, |
Yes. Two ideals should be compared with respect to the set inclusion. I think it is naturally. You can not compare two ideals with like (x) and (y) in ZZ[x,y]. In that case, we should not return false. We should just throw an error said they are not comparable. But I think we may need singular library to decide a>b false and b>a false. To raise a error. |
See #37409: Most users seem to expect ideals to compare equal if and only if they are mathematically equal. The current behaviour alternates between mathematical comparison and "compare generators" comparison, depending on the base ring, which is (1) internally inconsistent and (2) unintuitive to most users.
In this patch I propose to fail by default in the
._richcmp_()
method for generic ideals, except for trivial cases in which equality can easily be decided: If the parent ring does not implement a mathematically meaningful comparison operation for ideals, it should fail in a noticeable way, rather than silently falling back to a much weaker notion of equality.