Issue in Polynomial Modulo

[Taylor Huang]

Hi all,

I also posted the following to sage-devel conversation, but it may be more relevant to sage-support.

Cutting to the chase, I realized that the modulo operator "%" is un-naturally defined to be constant-zero in the fraction field of polynomials. This has caused the following issue.

See the following minimal code on the online Sage server: Sage Cell Server

In this example, we are doing 1 modulo x+1, which supposedly should give us 1 as output. However, since the datatype of x+1 is rational polynomial, it produces 0 as output.

I imagine there are two ways that may potentially solve this issue:
(1) Disgard the modulo operator % for fraction field! In the mathematical sense there is no interesting modulo (other than producing zero) for fraction field anyway, so such an operator seems more confusing than helpful. Removing % from fraction field should also cause the triggering of coersion from rational polynomial to a polynomial in the above example.
(2) Perform the modulo only on the integral ideal. Upon each time we compute f%g in a fraction field, we can derive its ring of integer O, and, return a representative in the co-set f + g*O. In the above example, this should also return the representative 1.

Best,
Yu-Hsuan (Taylor)

[Nils Bruin]

The analogue for QQ goes back to

https://github.com/sagemath/sage/issues/14870

where indeed a conversion of the modulus to integers is attempted (a coercion in that direction is not available). The implementation there skirts the coercion framework in sage entirely and it leads to buggy behaviour like:

sage: QQ(7)%(GF(5)(14))
3

which should of course be an error, since any way of interpreting a residue class in ZZ/5ZZ as a valid modulus for division in ZZ is going to be problematic. It should raise an error, justs as it does when the numerator is an integer:

sage: 7%(GF(5)(14))
ArithmeticError: reduction modulo 4 not defined

The error message is not formulated very informatively because the 4 looks just like an integer even though it is an element of GF(5).

I agree that QQ and QQ[x].field_of_fractions() should be handled analogously here,  but it looks like the sage way would be by either returning the mathematically correct but useless "0" or an error. Workarounds that try to do some conversions are bound to catch things that should really not be caught.