I took a look at this more closely and it appeared to me that a patch I previously applied to the fmpz_poly_pseudo_divrem function was not also applied to fmpz_poly_pseudo_div function. After applying that patch, FLINT returns the correct result for the example you gave.
Indeed this bug could also cause segfaults in the pseudo_div function. However now that you changed the code over to use pseudo_divrem you shouldn't be hitting a segfault from there. I don't believe that function is called from anything else in FLINT, so perhaps the other issues you noted were unrelated. Thanks for the bug report. This was a pretty serious bug. <PLUG>In FLINT 2 this sort of bug couldn't occur for at least 2 reasons. The necessity to set the maximum size of coefficients for polynomials is gone in FLINT 2. It is all automatic because it uses mpz_t's. Secondly, FLINT 2 will rationalise the number of functions by implementing fmpz_poly_pseudo_div as a special case of fmpz_poly_pseudo_divrem (it will still be faster and won't compute the remainder, it'll just be implemented all in one single function). FLINT 2 will also use Git, which will make keeping track of specific patches much easier too, though in this case I don't think that would have solved this problem. I can't wait for FLINT 2.</PLUG> Anyhow, I'm working hard today to get a new version of FLINT out with lots of new code and this and a few other critical bugs patched. I will make an announcement here and on the FLINT devel list when I have it up. Bill. On 22 Sep, 08:50, Bill Hart <goodwillh...@googlemail.com> wrote: > This does indeed look like a bug. I can't think of any reason off the > top of my head for the quotients to be different except that one of > them is wrong. > > I'm currently working on the next FLINT release and will be sure to > address this problem. There will probably be two FLINT releases > relatively soon after one another due to the large amount of code. The > releases might be a week or two apart and I don't want to hold up the > code that will be in the first release (which includes some critical > bug fixes) on account of the code that will be in the second release > (which includes lots of contributed code). > > Thanks for the report! > > Bill. > > On 22 Sep, 03:18, Sebastian Pancratz <s...@pancratz.org> wrote: > > > > > Dear all, > > > Yesterday I ran into a problem when using the FLINT pseudo division > > methods in SAGE. Below I am copying part of an email I sent to Bill > > Hart already. > > > Sebastian > > > [Bug report] > > While working on re-implementing QQ[] in SAGE, I came across the > > following inconsistency. From the FLINT 1.4.0 manual, I think the > > methods fmpz_poly_pseudo_divrem and fmpz_poly_pseudo_div should return > > the same quotient. But using the "div" method I get > > > A = x^4-4*x^2+2*x+2 > > B = x-2560 > > Q = x^3+2560*x^2+6553596*x+3892303874 > > m = 0 > > > whereas the "divrem" yields > > > A = x^4-4*x^2+2*x+2 > > B = x-2560 > > Q = x^3+2560*x^2+6553596*x+16777205762 > > m = 0 > > > The second answer is the correct one. Temporarily, I have now changed > > the relevant Cython code to > > > cdef fmpz_poly_t rem > > fmpz_poly_init(rem) > > fmpz_poly_pseudo_divrem(q.num, rem, &m, a.num, b.num) > > fmpz_poly_clear(rem) > > # fmpz_poly_pseudo_div(q.num, &m, a.num, b.num) > > > and it seems to work fine, as far as many random comparisons between > > the output of "f // g" with new QQ[] and with the old QQ[] suggest. > > Here is another example, for which the output doesn't agree: > > > f = -10*x^6 + x^5 + 2*x^4 - x^3 + 2*x^2 - x - 1 > > g = 75*x^4 - 1/2*x^3 - x^2 + 37/3*x - 1/124 > > > In case this helps, I am working with SAGE 4.1.2.alpha0 under Ubuntu > > 8.10. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
