id summary reporter owner description type status priority milestone component resolution keywords cc merged author reviewer upstream work_issues branch commit dependencies stopgaps
10635 refactor polynomial_element.pyx factor function was AlexGhitza "The ""factor"" function in polynomial_element.pyx needs to be refactored, because it has to be modified every time a new interesting base ring gets added to Sage.
Instead of importing a ton of different rings, the function should just call a method on the base ring, e.g.,
{{{
def _factor_univariate_polynomial(self, f):
...
}}}
Since the code in factor is for generic polynomials, it doesn't use their internal representation, so this should be fine. It just turns out that factoring algorithms depend a huge amount on the base ring, and polynomials get created over tons of different bases (but there are far less classes that derive from ""polynomial"").
I suggest for this ticket, at a minimum we add a quick ""hasattr"" check at the top of the current factor function, then leave the existing code. Then new code can be written to use this. In the near future somebody can move most of the imports and cases out the current factor function, so it becomes very short, and the code gets put in the right place.
A major motivation for this is that people create their own new rings R in external code that depends on sage, and want to be able to factor polynomials over R. They do *not* define a new class for polynomials over R. It seems silly for them to have to patch the core sage library to get factorization functionality.
----
Apply
1. [attachment:trac_10635-new_version_with_tests.patch]
1. [attachment:trac_10635-fix_doctest_error_due_to_noise.reviewer.patch]
to the Sage library.
" enhancement closed minor sage-4.7.2 basic arithmetic fixed sd32 sage-4.7.2.alpha3 Christopher Hall Mariah Lenox, William Stein, Simon Spicer N/A