Transfer ring-specific functionality of factor() and roots() in polynomial_element.pyx to the correct ring files

[haikona]

Ticket arises as a result of #10635. The methods factor() and roots() for generic univariate polynomial elements in rings/polynomial/polynomial_element.pyx have a lot of ring-specific code that would be better suited as methods attached to each individual base ring.

To whit, patch #10635 allows for the creation of _factor_univariate_polynomial() and _roots_univariate_polynomial() as dundermethods on the base ring. This should now be done, and the relevant code from factor() and roots() should be moved to these methods.

Depends on #10635
Depends on #13272
Depends on #13274
Depends on #13275
Depends on #13276

CC: @williamstein @saraedum

Component: basic arithmetic

Keywords: factor, roots, univariate polynomial, sd32

Reviewer: Peter Bruin

Issue created by migration from https://trac.sagemath.org/ticket/11731

[williamstein]

Changed keywords from factor, roots, univariate polynomial to factor, roots, univariate polynomial, sd32

[saraedum]

comment:3

I started to work on moving the code out of factor(). I'm trying to split this into several small tickets to make this easier for me to write and for someone else to review.

[saraedum]

Changed dependencies from #10635 to #10635, #13272, #13274, #13275

[saraedum]

Changed dependencies from #10635, #13272, #13274, #13275 to #10635, #13272, #13274, #13275, #13276

[pjbruin]

Reviewer: Peter Bruin

[pjbruin]

comment:5

I will try to review all the dependencies of this ticket.

[pjbruin]

comment:8

Are there more base rings for which we want to do this? The method Polynomial.factor() currently still has the following special cases:

• IntegerModRing, IntegerRing
• RelativeNumberField
• FiniteField
• NumberField
• RealField
• ComplexField

[saraedum]

comment:11

I guess we still want to fix this for the four remaining cases for factor():

• IntegerModRing
• IntegerRing
• FiniteField
• NumberField

roots() is a bit harder to clean up as the ring parameter makes it less clear who should have ownership of the implementation, so I'd probably leave it in the current state.

[mezzarobba]

comment:12

A drawback of using _*_univariate_polynomial methods is that it typically creates a dependency from the module implementing the base ring to that implementing the polynomials, which can be a bit annoying, especially with Cython code. This is not to say we shouldn't use them more, I'm just wondering if there is a better option.