Repository navigation
Add roots, complex_roots and real_roots #62
Description
Activity
Is this a problem because of refactoring (like a cyclic import)?
I guess
acbis the only type that would always be able to represent the roots of anyfmpz_polyorfmpq_polyalthough it probably shouldn't be used fornmod_poly.Perhaps e.g.
fmpz_polyshould have some sort of roots method that only finds integer roots? It doesn't look like Flint has an immediate function for that.Asking the user to convert to
acb_polyexplicitly does not seem unreasonable to me although it would be a breaking change.- added a commit that references this issue
on Aug 18, 2023 By default,
rootsought to return roots in the coefficient ring, e.g. integer roots forfmpz_polyand rational roots forfmpq_poly.This is supported explicitly by the generics system (though not all conversions have been implemented).
In
flint_ctypes, therootsmethod forgr_polycurrently looks like this:def roots(self, domain=None): """ Computes the roots in the coefficient ring of this polynomial, returning a tuple (``roots``, ``multiplicities``). If the ring is not algebraically closed, the sum of multiplicities can be smaller than the degree of the polynomial. If ``domain`` is given, returns roots in that ring instead. >>> (ZZx([3,2]) * ZZx([15,1])**2 * ZZx([-10,1])).roots() ([10, -15], [1, 2]) >>> ZZx([1]).roots() ([], []) We consider roots of the zero polynomial to be ill-defined: >>> ZZx([]).roots() Traceback (most recent call last): ... ValueError We construct an integer polynomial with rational, real algebraic and complex algebraic roots and extract its roots over different domains: >>> f = ZZx([-2,0,1]) * ZZx([1, 0, 1]) * ZZx([3, 2])**2 >>> f.roots() # integer roots (there are none) ([], []) >>> f.roots(domain=QQ) # rational roots ([-3/2], [2]) >>> f.roots(domain=AA) # real algebraic roots ([Root a = 1.41421 of a^2-2, Root a = -1.41421 of a^2-2, -3/2], [1, 1, 2]) >>> f.roots(domain=QQbar) # complex algebraic roots ([Root a = 1.00000*I of a^2+1, Root a = -1.00000*I of a^2+1, Root a = 1.41421 of a^2-2, Root a = -1.41421 of a^2-2, -3/2], [1, 1, 1, 1, 2]) >>> f.roots(domain=RR) # real ball roots ([[-1.414213562373095 +/- 4.89e-17], [1.414213562373095 +/- 4.89e-17], -1.500000000000000], [1, 1, 2]) >>> f.roots(domain=CC) # complex ball roots ([[-1.414213562373095 +/- 4.89e-17], [1.414213562373095 +/- 4.89e-17], 1.000000000000000*I, -1.000000000000000*I, -1.500000000000000], [1, 1, 1, 1, 2]) >>> f.roots(RF) # real floating-point roots ([-1.414213562373095, 1.414213562373095, -1.500000000000000], [1, 1, 2]) >>> f.roots(CF) # complex floating-point roots ([-1.414213562373095, 1.414213562373095, 1.000000000000000*I, -1.000000000000000*I, -1.500000000000000], [1, 1, 1, 1, 2]) Calcium examples/tests: >>> PolynomialRing(CC_ca)([2,11,20,12]).roots() ([-0.666667 {-2/3}, -0.500000 {-1/2}], [1, 2]) >>> PolynomialRing(RR_ca)([1,-1,0,1]).roots() ([-1.32472 {a where a = -1.32472 [a^3-a+1=0]}], [1]) >>> PolynomialRing(CC_ca)([1,-1,0,1]).roots() ([-1.32472 {a where a = -1.32472 [a^3-a+1=0]}, 0.662359 + 0.562280*I {a where a = 0.662359 + 0.562280*I [a^3-a+1=0]}, 0.662359 - 0.562280*I {a where a = 0.662359 - 0.562280*I [a^3-a+1=0]}], [1, 1, 1]) """ Rx = self.parent() R = Rx._coefficient_ring mult = VecZZ() if domain is None: roots = Vec(R)() status = libgr.gr_poly_roots(roots._ref, mult._ref, self._ref, 0, R._ref) else: C = domain roots = Vec(C)() status = libgr.gr_poly_roots_other(roots._ref, mult._ref, self._ref, R._ref, 0, C._ref) if status: if status & GR_UNABLE: raise NotImplementedError if status & GR_DOMAIN: raise ValueError return (roots, mult)The generics system in FLINT3 is really beautiful. Potentially the reworking into submodules in #61 ties in really nicely with the generics from FLINT3, as we can have these as parent classes of specific types.
For now what I've marked ready should be "fine" but it's really only baby steps to something which hopefully is more modular and easier to develop.
rootsought to return roots in the coefficient ring, e.g. integer roots forfmpz_polyand rational roots forfmpq_polyDoes Flint already have functions for computing these?
I didn't see anything in the docs for
fmpz_polyandfmpq_polywhen I looked earlier.Is there a more efficient method than just calling
factor?I would have thought that linear factors could be found more efficiently somehow than by computing a full factorisation.
Does Flint already have functions for computing these?
Within the generics system
gr_poly_roots_otheroffers such an interface. For example to support computing thearbroots of anfmpzpoly, thearbdomain provides this code: https://github.com/flintlib/flint2/blob/dcd25c0eb86defc67b5c42b270da8a9b68aa004b/src/gr/arb.c#L1634Such code ought to be factored out to dedicated functions at least for the most common cases (e.g.
fmpzpoly ->arbroots); this just hasn't been done yet.I would have thought that linear factors could be found more efficiently somehow than by computing a full factorisation.
Yes, this is definitely possible. There is such root-finding code for
fmpz_modpolynomials, but for many other cases (e.g.fmpz) an optimized algorithm hasn't been implemented yet.If it is causing refactoring problems then I think that it is fine to just remove the
fmpz_polyetc roots methods and leaverootsas a method onacb_poly. If longer term we don't want to havefmpz_poly.rootsreturnacbthen at some point there will be a compatibility break so we might as well just remove it now.I suggest adding a CHANGELOG section in the README file with a section for version
0.5.0and saying that therootsmethod is removed butacb_poly(p).roots()can be used instead.Yeah. We can even have a depreciated function for flint_poly.roots() which points to the right way to use acb.roots()
Just to add to this, the method of
roots()currently onfmpz_polydoesn't convert then call roots, but instead computes complex roots as its own method. Which feels like the wrong thing to do for me, but obviously someone else disagreespython-flint/src/flint/fmpz_poly.pyx
Lines 323 to 368 in da48588
Yes, that code ought to be changed.
I was looking at the docs and found that, for example, fmpz_poly has methods to find complex and real roots but not integer roots?
https://flintlib.org/doc/fmpz_poly.html
Are integer roots a Flint3 thing? Not sure how to progress best with this issue
fmpz_poly has methods to find complex and real roots but not integer roots?
A complete factorisation algorithm can always find roots in the ground domain of any polynomial. Both
fmpz_polyandfmpq_polycan use.factor()and check for linear factors. As mentioned above faster algorithms are not yet implemented.Haha I just returned to this issue to say I realised this. I'll work on a naive implementation which returns a list of the (negative of) the constant coefficient of each linear factor and then we can also expose real_roots() and complex_roots()
Looks like we have
rootsandcomplex_rootsnow but notreal_roots.Types were these methods do not make sense should raise something like DomainError rather than
AttributeError:In [3]: nmod_poly([1, 1], 10).complex_roots() --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) Cell In[3], line 1 ----> 1 nmod_poly([1, 1], 10).complex_roots() File flint/flint_base/flint_base.pyx:262, in flint.flint_base.flint_base.flint_poly.complex_roots() AttributeError: Complex roots are not supported for this polynomial
- changed the title
[-]Template class calls `acb_poly` for method definition[/-][+]Add roots, complex_roots and real_roots[/+]on Aug 26, 2024 Maybe we can go through in a new PR and add failures for the real roots and make sure the error raised is DomainError then?
Yes, that sounds right.
I left some comments about
real_roots: #199 (comment).There are two things to consider:
- Should
fmpz_poly.real_roots()usearb_fmpz_poly_complex_rootsoracb_poly_validate_real_roots(or something else)? - Should there be a uniform interface for roots methods?
In [12]: acb_poly([1, 0, -1]).roots() Out[12]: [-1.00000000000000, 1.00000000000000] In [13]: fmpz_poly([1, 0, -1]).roots() Out[13]: [(1, 1), (-1, 1)]
It isn't possible to handle multiplicity correctly for
arb_polyoracb_polybecause exact square-free factorisation is needed for that and if the poly is square-free then the multiplicity would always be 1. Maybe that just means that they have to be different...- Should
Another issue is about overlapping roots:
In [3]: r1 = 10**100 In [4]: r2 = 10**100 + 1 In [5]: x = fmpz_poly([0, 1]) In [6]: p = (x - r1)*(x - r2)**2 In [7]: p.complex_roots() Out[7]: [([1.00000000000000e+100 +/- 3e+81], 1), ([1.00000000000000e+100 +/- 3e+81], 2)] In [8]: [(rr1, _), (rr2, _)] = p.complex_roots() In [9]: rr1.overlaps(rr2) Out[9]: True
Ideally these roots would be refined until they no longer overlap but since they come from distinct square free factors that doesn't happen. If the multiplicities are equal then it should be possible to distinguish them:
In [10]: p = (x - r1)*(x - r2) In [11]: [(rr1, _), (rr2, _)] = p.complex_roots() In [12]: rr1.overlaps(rr2) Out[12]: False
I guess that is why we want to use
arb_fmpz_poly_complex_rootsbecause it guarantees this isolation but it only does it one square-free factor at a time.Maybe we need to take the square-free part (radical) of the polynomial and use that to compute the roots but then identify each root with a square-free factor of known multiplicity somehow (e.g. by evaluating each factor at each root, but then might need to increase precision...).
This approach can be used to handle multiplicity of different roots while ensuring that they don't overlap. This is for
fmpz_poly:from flint import * def complex_roots(p, prec=None): return _roots(p, prec, real=False) def real_roots(p, prec=None): return _roots(p, prec, real=True) def _roots(p, prec, real): """Real roots of an fmpz_poly.""" if prec is None: prec = ctx.prec _, fac = p.factor_squarefree() rad = p / p.gcd(p.derivative()) while True: roots = _get_roots(fac, rad, prec, real) if roots is not None: return roots prec *= 2 def _get_roots(fac, rad, prec, real): """Get real roots from squarefree factors and radical. If prec is not high enough returns None. """ oldprec = ctx.prec ctx.prec = prec # Current implementation except should be simplified # to avoid factorisation. complex_roots = rad.complex_roots() # prec affects rad.complex_roots() and f(r) # May as well use a higher precision for f(r) ctx.prec *= 2 roots = [] for r, m_ in complex_roots: assert m_ == 1 if real and not r.imag.overlaps(0): break elif real: r = r.real roots.append(r) roots_mult = [] for r in roots: factor_already_found = False for f, m in fac: if f(r).overlaps(0): if factor_already_found: # Could be a root of two factors... return None else: factor_already_found = True roots_mult.append((r, m)) ctx.prec = oldprec return roots_mult
I don't know if there is some better way than this.
Of course there should be a shortcut for the case where the original polynomial has only one square-free factor.
The
flint_polyis a child class offlint_elemand is used to build other polynomial types on top of, however,flint_polyhas a methodroots()which converts the self toacbtype, which I assume is not the intension.Suggestion is to remove this method and include it to
acbif needed.python-flint/src/flint/pyflint.pyx
Lines 215 to 220 in 71bf110