Ideals of $\mathbb Z[x]$

[Thrashophil]

Steps To Reproduce

R.<x> = ZZ[]
I = R.ideal(1-2*x,2)
I.is_trivial()

Expected Behavior

The output should be True instead of False because we have $1=(1−2x)+2x∈I$.

Actual Behavior

The output is False.

Additional Information

No response

Environment

- **OS**: EndeavourOS (Linux 6.6.16-1-lts x86_64)
- **Sage Version**: 10.2

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[yyyyx4]

This ideal inherits its comparison function from Ideal_generic._richcmp_(), which compares the sets of generators (?!) instead of comparing the actual ideal.

[grhkm21]

I laughed

sage: R.<x> = ZZ[]
....: R.ideal(1) == R.ideal(1, 2)
False

[tscrim]

It is perfectly fair for == to compare two ideals in a non-mathematical way. You don't necessarily want to invoke hard computational tests for things that could be trivial. How would you expect it to work in that level of generality?

This is basically a(nother) case of not having a good way to say "IDK", and so it simply returns False. So this isn't really a bug IMO but a missing feature.

[yyyyx4]

It is perfectly fair for == to compare two ideals in a non-mathematical way.

I disagree: As the existence of this issue demonstrates, it is unexpected and causes confusion. If we wanted to compare the generators, we'd compare the generators.

You don't necessarily want to invoke hard computational tests for things that could be trivial.

I'm not sure what this refers to, can you elaborate?

This is basically a(nother) case of not having a good way to say "IDK", and so it simply returns False. So this isn't really a bug IMO but a missing feature.

The generally accepted way to communicate "IDK" is to throw a NotImplementedError, not to run some arbitrary fallback that returns a reasonably-looking value but doesn't actually do what everyone would expect.

On a related note, there really should be a distinction between mathematically meaningful comparisons and simple comparisons for programming purposes, cf. #35546 (comment).

[tscrim]

It is perfectly fair for == to compare two ideals in a non-mathematical way.

I disagree: As the existence of this issue demonstrates, it is unexpected and causes confusion. If we wanted to compare the generators, we'd compare the generators.

Surprising behavior does not imply wrong behavior. Of course, it should be avoided, but we need to accept it sometimes. Here, there are two issues: (1) Sometimes one needs to be careful with False results to differentiate between "cannot prove" and "actually false" but it is very difficult to explain this in all the places one should be careful. (2) We cannot easily communicate that we cannot do the computation here.

You don't necessarily want to invoke hard computational tests for things that could be trivial.

I'm not sure what this refers to, can you elaborate?

This might invoke a full Grobner basis computation when you simply want to check they are more trivially not equal. Of course, there are alternatives in this specific case, but there are uses for == diverging from a natural mathematical definition:

sage: R.<x> = PolynomialRing(ZZ, implementation='FLINT')
sage: S.<x> = PolynomialRing(ZZ, implementation='NTL')
sage: R == S
False

There is also the issue that Python stipulates that X == Y should imply hash(X) == hash(Y)... To have that, we really would need to create a GB to hash the ideal. (Although mpolynomial ring ideals take an easy way out and just hash to 0.)

This is basically a(nother) case of not having a good way to say "IDK", and so it simply returns False. So this isn't really a bug IMO but a missing feature.

The generally accepted way to communicate "IDK" is to throw a NotImplementedError, not to run some arbitrary fallback that returns a reasonably-looking value but doesn't actually do what everyone would expect.

That is not true. SR and lazy series, for example, behave in this way. There is also an important distinction between IDK because the computation is hard versus IDK because there nothing implemented at all.

Would you really want generic ideals to raise an error anytime they cannot compare in the strict mathematical sense? Then they couldn't be used as keys for dicts either. These would be the consequences I can immediately think of, but there are likely many more that would render these generic implementations completely unusable.

On a related note, there really should be a distinction between mathematically meaningful comparisons and simple comparisons for programming purposes, cf. #35546 (comment).

Defining natural comparisons is hard. There can be many different versions that have different uses. We usually just have to chose one, explain what it is, and explain how to use other choices. It also shows up in subtle ways in different methods.

[YijunYuan]

It is perfectly fair for == to compare two ideals in a non-mathematical way. You don't necessarily want to invoke hard computational tests for things that could be trivial. How would you expect it to work in that level of generality?

This is basically a(nother) case of not having a good way to say "IDK", and so it simply returns False. So this isn't really a bug IMO but a missing feature.

It is OK to do math in a non-mathematical way?

All you need is a NotImplementedError, but you insist on returning a False.

You can't fake an answer instead of admitting the inability.

Similar issue: #36266

[YijunYuan]

The most important thing is that it is not the responsibility of any common user of SageMath to distinguish whether it is a real False in the mathematical sense or it is just a sign that SageMath is giving up.

[tscrim]

#36266 is a different issue (it seems nobody has changed the implementation with the appropriate category from a very quick look).

Python doesn't allow for trilean logic (which I would like to have, but others have tried and found it complicated from what I heard), and raising an error propagates breakage that might otherwise be okay (in fact, would make large amounts of things like, e.g., symbolics unusable).

On the contrary, a good mathematician would look for a certificate (in this case, something in one ideal that isn't in the other). Even more so, things can be fully implemented but can lead to "wrong" results because a different convention is used in Sage than the user did for their conjectures (this is from a true story). This is why we believe in open source; we can look at the code and see how things like == are implemented.

Forgive the Clinton-esque comment, but it depends on what the definition of == is. Perhaps it was too colloquial for me to have said "non-mathematical". More precisely, defining == on ideals by comparing generators is a valid notion of equality (clearly a reflexive, symmetric, transitive relation), but it doesn't give the "standard" notion of equality of sets.

TL;DR False is valid here.

[tscrim]

For comparison:

sage: R.<x> = PolynomialRing(ZZ, 1)
sage: I = R.ideal([1-2*x, 2])
sage: I.is_trivial()
True

This is because it uses the (lib)singular implementation, which has the GB implemented (and so the comparisons of ideals as sets through __richcmp__).

[YijunYuan]

On the contrary, a good mathematician would look for a certificate (in this case, something in one ideal that isn't in the other). Even more so, things can be fully implemented but can lead to "wrong" results because a different convention is used in Sage than the user did for their conjectures (this is from a true story).

Let's say the current implementation of == is reasonable (which I doubt). The bottom line here is that every ambiguous behavior like this should be well-documented. However, SageMath's document sucks haven't done this.

This is why we believe in open source; we can look at the code and see how things like == are implemented.

Not every user is a good programmer. Even so, USERS should only be exposed to documentation and the open (in the software engineering sense) interface of this software. To them, there is no clear line between "feature" and "bug".

[tscrim]

On the contrary, a good mathematician would look for a certificate (in this case, something in one ideal that isn't in the other). Even more so, things can be fully implemented but can lead to "wrong" results because a different convention is used in Sage than the user did for their conjectures (this is from a true story).

Let's say the current implementation of == is reasonable (which I doubt). The bottom line here is that every ambiguous behavior like this should be well-documented. However, SageMath's document sucks.

Let me apologize that this community of volunteers has not produced sufficient documentation that meets your high expectations. You are welcome to try and improve it.

This is why we believe in open source; we can look at the code and see how things like == are implemented.

Not every user is a good programmer. Even so, USERS should only be exposed to documentation and the open (in the software engineering sense) interface of this software. To them, there is no clear line between "feature" and "bug".

In principle, I agree with you except the last part. If a user cannot understand the difference of desired behavior and undesired behavior, then I believe they will likely have difficulties understanding difficult mathematics that can have far more subtle points. In this case though, one doesn't need to be a good programmer to understand what the comparison code is doing.

That being said, this here is definitely a case where we can improve our documentation by saying the generic implementation uses only the generators for comparisons.

[YijunYuan]

Let me apologize that this community of volunteers has not produced sufficient documentation that meets your high expectations. You are welcome to try and improve it.

I should apologize for the inappropriate word sucks. It is offensive.

[yyyyx4]

The biggest issue is that the generic implementation does something entirely different from the specialized implementations. What comparison of ideals should be doing is ultimately a matter of opinion (although I do have a very strong opinion on this), but the fact that specialized implementations behave differently from the generic fallback is definitely harmful. It means, for example, that comparison suddenly starts returning wildly different results if you change the code to a slightly different base ring (or even just a different implementation of the same base ring). Subtle details like that are certainly not transparent to most users, and they would realistically cause lots of bugs/suffering even if they were properly documented. There should be a clear specification of what comparison does, and all implementations should either adhere to it or give up and throw a NotImplementedError. (In fact, the same should ideally hold for all other functions in Sage!)