#16276: fixes PolynomialElement.mod()
-------------------------------------+-------------------------------------
Reporter: Bouillaguet | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: basic arithmetic | Resolution:
Keywords: | Merged in:
Authors: Charles | Reviewers:
Bouillaguet | Work issues:
Report Upstream: N/A | Commit:
Branch: | 0061d17ca5e04465c1189d62aa032f98a0c120cf
u/Bouillaguet/ticket/16276 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by Bouillaguet):
Hi all,
In fact, most of my rant comes of out of the following: the name "quo_rem"
strongly suggests euclidean division (at least for me). In particular, the
QUOtient bit. Because of how the system works, the {{{quo_rem()}}} method
is also available on non-euclidean rings, where euclidean division does
not make sense (but where exact division sometimes make sense, e.g. over
integral domains).
I thought that the "remainder" (which makes sense mathematically as
everyone agrees) could be obtained by :
{{{
sage: R.<x> = ZZ[]
sage: Ideal(2*x+1).reduce(x^100)
x^100
}}}
(and given the remainder, the "quotient" part could be obtained by exact
division).
But it turns out that this is not always the case:
{{{
sage: Ideal(3).reduce(5*x+7)
Traceback (most recent call last)
...
TypeError: not a constant polynomial
sage: Ideal(R(3)).reduce(5*x+7)
5*x + 7 # <--- not what you want, and probably incorrect?
}}}
This is yet another inconsistency.
Lastly, let me mention that the NTL implementation of ZZ[X] already does
what I thought was right (git blame tells dmharvey wrote it):
{{{
R.<x> = PolynomialRing(ZZ, implementation="NTL")
sage: sage: (x^100).quo_rem(2*x+1)
Traceback (most recent call last)
...
ArithmeticError: division not exact in Z[x] (consider coercing to Q[x]
first)
}}}
This is actually where I copied-pasted the error message (and some of the
code I think).
Anyway, I don't want to put up a fight about this. I don't care. I will
thus retract the modifications to FLINT's polynomial (which will remain
inconsistent with NTL). The fix to the "mod" method should still be
accepted by everyone though.
--
Ticket URL: <http://trac.sagemath.org/ticket/16276#comment:23>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
