#13629: provide xgcd for new polynomial rings through
_xgcd_univariate_polynomial
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner: AlexGhitza
Type: task | Status: needs_review
Priority: minor | Milestone: sage-6.4
Component: basic arithmetic | Resolution:
Keywords: sd59 | Merged in:
Authors: Julian Rueth | Reviewers: Peter Bruin
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/pbruin/13629-xgcd_univariate_polynomial|
828b5fc1a62567b98e35167cf686c59340b521f6
Dependencies: #13628, #18461, | Stopgaps:
#18467 |
-------------------------------------+-------------------------------------
Comment (by pbruin):
Replying to [comment:27 bruno]:
> With the current state of this ticket, there are two implementations of
`_xgcd_univariate_polynomial`, one in the class `Field` (in
`src/sage/rings/rings.pyx`) and one in the class `ParentMethods` of the
class `Fields` (in `src/sage/categories/fields.py`).
>
> 1. In which case(s) will each of these implementations be used?
The implementation in `sage.rings.ring.Field` is used if the base ring
inherits from `Field`.
The implementation in `sage.categories.fields.Fields.ParentMethods` is
used if the base ring is a field but does not inherit from `Field`; the
method is then looked up by the category framework.
The latter situation is sometimes detected only at runtime:
{{{
sage: R = Zmod(7)
sage: R._xgcd_univariate_polynomial
Traceback (most recent call last):
...
AttributeError: 'IntegerModRing_generic_with_category' object has no
attribute '_xgcd_univariate_polynomial'
sage: R in Fields()
True
sage: R._xgcd_univariate_polynomial
<bound method
IntegerModRing_generic_with_category._xgcd_univariate_polynomial of Ring
of integers modulo 7>
}}}
I suspect it is a feature (to avoid a potentially costly primality test)
and not a bug that the method only appears after we have forced `R` to
refine its category...
> 2. Is the implementation in `Fields` really needed?
I think it is, as the above example shows.
> I note that the exact same questions are equally relevant for the
positive-reviewed (by myself!) ticket #18461. I simply did not think of
that issue before.
I did have the above picture in mind when working on both tickets, and I
am afraid the situation is unavoidable without lots of refactoring.
One thing that could be done to reduce duplication is making `quo_rem` the
primitive operation that base rings of polynomial rings should implement,
instead of the two operations `_[x]gcd_univariate_polynomial`. That would
be something for a follow-up ticket, though.
--
Ticket URL: <http://trac.sagemath.org/ticket/13629#comment:28>
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.
