refuse to compare two ideals that we don't know how to compare #41040
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.
This is only a partial order... right? cf. how are ZZ[x,y] currently compared?
There was a problem hiding this comment.
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.
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.
Yup. Even the comparison between standard Python sets is only partial. Related comments: #37409 (comment), #35546 (comment).
There was a problem hiding this comment.
what is "comparison by generators" for PIDs? Shouldn't one rather check for the mathematically correct "gen1 in (gen2) and gen2 in (gen1)" ?
There was a problem hiding this comment.
As far as I can tell, all PIDs that I could immediately think of are doing it right, i.e., perform a mathematical comparison. In some PIDs (such as ZZ, QQ['x']) the generators are normalized (non-negative resp. monic), hence simply comparing the generators would also work.
There was a problem hiding this comment.
hmm, gens of (f) for f in GF(q)[x] normalised too? is monic enough?
There was a problem hiding this comment.
They appear to be monic over GFs as well. (In a PID, the generator of any ideal is unique up to scaling by units, so monic is indeed enough to get a canonical generator for the ideal.)
In any case, I'm not sure I understand what your questions are about: Are you worried that we're still not comparing ideals correctly after this patch? Or are you suggesting that it could be done in a simpler/faster/better way for PIDs?
|
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. It is an important fix. We cna not return a error result to user. |
sagemathgh-41040: refuse to compare two ideals that we don't know how to compare See sagemath#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. URL: sagemath#41040 Reported by: Lorenz Panny Reviewer(s): Lorenz Panny, user202729
5 participants
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.