mua's profile - activity

Also when i tried adding a dummy variable in the polynomial ring and type casting the polynomials p and q as multivariate polynomials it was computed very fast. Any reason for why it happens differently when it is a multivariate polynomial over a fraction field versus a univariate polynomial over a fraction field?

thank you so much for the reply. We are building some packages for sagemath and this gcd is getting called in them. Can you probably explain what you mean by the limitations of sage math - is it for example because of the limitations of singular (Since in the multiplication function it calls the gcd function in multi_polynomial_libsingular.pyx and always hangs there since the number of monomials is big) ? or is it something else in the architecture? The reason I was asking is because I was wondering if it can be ``rectified" if we spend more time on it? or would it be a complete overhaul of the code?

thank you! that will be great!

yes I understand that. I will edit the question with more details.

I have to compute the gcd of univariate polynomials over the fraction field of $\mathbb{Z}[x,y]$. I wanted to use the subresultant algorithm already implemented for UFDs. I copied the same function to fraction_field.py. The subresultant algorithm calls the psuedo division algorithm which has the following step : R = dR - cB.shift(diffdeg) - this hangs when we consider random polynomials of degree >6 in $Frac(\mathbb{Z}[x,y])[z]$.

(Note: In the current version of sage it uses the regular Euclidean algorithm implemented in rings.py for computing gcd in this case. It is much slower than the subresultant algorithm (hangs for degrees >4) which is why I thought the subresultant algorithm will improve things.)

Sample input: sage: A.<x,y>=ZZ[]

sage: B= Frac(A)

sage: C.<z> = B[]

sage: p = C.random_element(6)

sage: q = C.random_element(6)

sage: gcd(p,q)

The following function is what I copied into fraction_field.py from unique_factorisation_domain.py.

def _gcd_univariate_polynomial(self, f, g):

    if f.degree() < g.degree():
        A,B = g, f
    else:
        A,B = f, g

    if B.is_zero():
        return A

    a = b = self.zero()
    for c in A.coefficients():
        a = a.gcd(c)
        if a.is_one():
            break
    for c in B.coefficients():
        b = b.gcd(c)
        if b.is_one():
            break

    d = a.gcd(b)

    #d=1
    A = A // a
    B = B // b
    g = h = 1

    delta = A.degree()-B.degree()
    _,R = A.pseudo_quo_rem(B)

    while R.degree() > 0:
        A = B
        B = R // (g*h**delta)
        g = A.leading_coefficient()
        h = h*g**delta // h**delta
        delta = A.degree() - B.degree()
        _, R = A.pseudo_quo_rem(B)
       # print("i am here")


    if R.is_zero():
        b = self.zero()
        for c in B.coefficients():
            b = b.gcd(c)
            if b.is_one():
                break

        return d*B // b

    return d

This calls the following pseudo quo remainder function in polynomial_element.pyx. It is in this function I was able to see that it hangs at R = dR - cB.shift(diffdeg).

def pseudo_quo_rem(self,other):

    if other.is_zero():
        raise ZeroDivisionError("Pseudo-division by zero is not possible")

    # if other is a constant, then R = 0 and Q = self * other^(deg(self))
    if other in self.parent().base_ring():
        return (self * other**(self.degree()), self._parent.zero())

    R = self
    B = other
    Q = self._parent.zero()
    e = self.degree() - other.degree() + 1
    d = B.leading_coefficient()

    while not R.degree() < B.degree():

        c = R.leading_coefficient()

        diffdeg = R.degree() - B.degree()

        Q = d*Q + self.parent()(c).shift(diffdeg)

        R = d*R - c*B.shift(diffdeg)

        e -= 1

    q = d**e
    return (q*Q,q*R)