On Monday, 6 October 2025 at 13:21:12 UTC-7 [email protected] wrote: I do not understand this question. It's a field. So everything is good.
I think the observation is that if a%b is predictably 0 then why have the operator at all? There are also cases where the coercion framework gets in the way. For instance with R.<x> = QQ[] ((x+1)/(x-2)) % (x-1) could just work in a well-defined way, since the denominator is coprime to the modulus. But it doesn't, because in this case the coercion framework gets its hands on the modulus first and coerces it into the fraction field. In the case of integers and rationals, this is caught by a custom QQ.__mod__ that tries to recover an integer from the modulus: QQ(2/3) % 5 but it is a little too greedy in doing so, so we get some nonsensical things back as well: QQ(2/3) % GF(7)(12) I think the latter is actually worse than QQ(2/3) % QQ(5) returning an error or 0, so there is definitely a bug report hiding here somewhere. Whether it's the behaviour originally pointed out is a matter to analyze elsewhere. Perhaps a better way to explain this to the coercion framework is to have a partial "right-action" of ZZ on QQ through % (which is going to be just some partial map from QQ x ZZ -> QQ; no nice properties otherwise). These cases show that just treating "%" as a binary operator where one should strive for common parents is perhaps not the best fit. -- 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/2fa1fe98-10a1-4629-85b6-06ace347f077n%40googlegroups.com.
