This question was also posed on sage-support. Probably the most important thing is that x = y*(x//y) + (x%y) to maintain consistency.
Presently that actually fails in QQ, because there is a work-around there to make "%" something else than just constant 0: 3*QQ(2)//QQ(3)+(QQ(2)%QQ(3)) There are other side-effects of the way in which the work-around on QQ.__mod__ is implemented that lead to nonsensical results; see the comment on the sage-support threat: https://groups.google.com/g/sage-support/c/uuVTX2s7Xvk So, clearly: having "%" just return 0 on fields is not useful in itself. However, it does provide consistency between operators, which can mean that certain generically implemented algorithms can be applied unchanged between ZZ and QQ, for instance. If we value "%" being a little bit more useful even at the cost of breaking consistency then we should take a careful look at how to do that while avoiding the problems that are currently arising for QQ.__mod__ . It would be nice for Z subset QQ and F[x] subset F(x) to be in step on this, but then improve the QQ case in the process. It is the case that the difference between ZZ and QQ is important in sage and that users who are running into problems with them not being separated appropriately probably will run into problems further down the line anyway, even if this particular hurdle is modified. Same for F[x] and F(x). On Monday, 6 October 2025 at 11:21:54 UTC-7 [email protected] wrote: > Thas't normal. Corece it yourself. > > Le dim. 5 oct. 2025 à 14:12, Taylor Huang <[email protected]> a écrit > : > > > > Hi all, > > > > 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) > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion visit > https://groups.google.com/d/msgid/sage-devel/56a6410d-3644-4b7a-9181-d0911d1dee17n%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/5a37a656-7231-449b-9ab6-58b2c0dc6fcen%40googlegroups.com.
