Do not require coefficient's __nonzero__ to be implemented for polynomial printing

[saraedum]

Currently, a polynomial prints all the coefficients that are non-zero.

sage: R.<x> = QQbar[]
sage: R([1,0,1])
x^2 + 1

This of course makes perfect sense but leads to issues when determining whether an element is zero or not is not possible or very hard as is the case with some of the elements introduced in #22956.

There, we essentially have the following situation:

sage: def __nonzero__(self):
....:     raise NotImplementedError()
....: 
sage: sage.rings.qqbar.AlgebraicNumber.__nonzero__ = __nonzero__
sage: R.<x> = QQbar[]
sage: R([1,0,1])
NotImplementedError

This ticket changes the printing to print an element even if __nonzero__ raises an error:

sage: R.<x> = QQbar[]
sage: R([1,0,1])
x^2 + 0*x + 1

CC: @nbruin

Component: commutative algebra

Keywords: sd86.5

Author: Julian Rüth

Branch/Commit: 0734fc5

Reviewer: David Roe

Issue created by migration from https://trac.sagemath.org/ticket/23020

[saraedum]

Branch: u/saraedum/do_not_require_coefficient_s___nonzero___to_be_implemented_for_polynomial_printing

[saraedum]

Changed keywords from none to days86.5

[saraedum]

New commits:

2e74e54

Do not require `__nonzero__` to be implemented for polynomial printing

[saraedum]

Commit: 2e74e54

[mezzarobba]

comment:4

I'm not sure if this is relevant, but in many Sage rings, __nonzero__() is understood as “syntactically nonzero” or “not trivially zero”, as opposed to “known not to be zero”. For example, elements of RIF, CIF, RBF, CIF etc. that contain zero but are not point intervals are __nonzero__() . At least some of the generic polynomial/matrix/... code respects this convention. I think it would make sense to have everything in Sage use this definition.

[saraedum]

comment:5

Thanks for pointing this out. I discussed this with nbruin and we think that regardless, printing of coefficients should be more robust with such exceptions; there is even a point in replacing NotImplementError here with Exception (note that this excludes things such as KeyboardInterrupt.)
So, you are right that I should probably adapt my private code, to implement __nonzero__ differently. But this change makes sense nevertheless.

[saraedum]

Changed keywords from days86.5 to sd86.5

[roed314]

comment:8

Looks good to me.

[vbraun]

comment:9

Merge conflict

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

0734fc5

Merge branch 'develop' into t/23020/do_not_require_coefficient_s___nonzero___to_be_implemented_for_polynomial_printing

[sagetrac-git]

Changed commit from 2e74e54 to 0734fc5

[saraedum]

Reviewer: David Roe

[saraedum]

comment:11

Sorry. We do not get any conflicts with the latest beta.

---

New commits:

0734fc5

Merge branch 'develop' into t/23020/do_not_require_coefficient_s___nonzero___to_be_implemented_for_polynomial_printing

---

New commits:

0734fc5

Merge branch 'develop' into t/23020/do_not_require_coefficient_s___nonzero___to_be_implemented_for_polynomial_printing

[vbraun]

Changed branch from u/saraedum/do_not_require_coefficient_s___nonzero___to_be_implemented_for_polynomial_printing to 0734fc5