I think there might have been some progress: sage: R.<x> = QQ[] sage: f = 3/2*x - 1/3 sage: _ = f % f Begin: fmpz_poly_pseudo_divrem(quo, r.num, &m, a.num, b.num) a.num = 9*t-2 fmpz_poly_length(a.num) = 2 fmpz_poly_max_limbs(a.num) = 1 b.num = 9*t-2 fmpz_poly_length(b.num) = 2 fmpz_poly_max_limbs(b.num) = 1 quo = 1 r.num = 0 m = 120658626 End: fmpz_poly_pseudo_divrem Begin: fmpz_pow_ui(t, lead, m) t = 0 fmpz_size(t) = 0 lead = 9 fmpz_size(lead) = 1 m = 120658626 End: fmpz_pow_ui
--- I'll upload a patch to #4000 in a few minutes so that someone else (Alex?) could confirm that the problem they experience arises in a similar way. --- The above output shows that the "fmpz_pow_ui" takes a long time for a good reason: it's computing t = 9^120658626. So the next question is, why is the m this large? The value of m is set by the call "fmpz_poly_pseudo_divrem(quo, r.num, &m, a.num, b.num)", where as the output above shows we have a.num and b.num both equal the polynomial 9*t-2. From the FLINT (1.5.0) manual, this call should set quo=Q, r.num=R and m such that lead(B)^m*A = B*Q + R and the degree of R is less than the degree of B, where a.num=A, b.num=B and lead(B) is the leading coefficient of B. Here we have A = B = 9*t-2 and lead(B) = 9. The output above shows that Q and R are computed correctly as 1 and 0, but I would expect that m should be set to 0 rather than 120658626. Nonetheless, I haven't managed to reproduce this in plain C (with std=c99 and FLINT) yet, so at the moment I am still clueless regarding how to fix this problem. Sebastian -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org