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
