I was just studying the asymptotically fast division code in MPIR (used for division in the FFT range), and I have just spotted what I believe is a serious bug.
The value returned by mpn/generic/invert.c almost always returns the wrong result. The associated test code for this code checks two inequalities. But after checking the first inequality, it overwrites the return value (pass/fail) with the result from the second inequality. Thus the first inequality is effectively never checked. Therefore, the test code never picks up the fact that the return value from invert.c is almost always too large. Presumably our division code doesn't actually return wrong answers because of this. It treats the inverse as approximate and adjusts. But one imagines there is the potential that it occasionally returns incorrect results or runs more slowly than it ought. Of course we have tested the division code extensively, so the likelihood of hitting such an incorrect value by chance is probably remote. But I felt it best to disclose the bug in invert.c as soon as possible. Note that invert.c almost always returns incorrect results. But it is presumably not being used directly by anyone. It's not part of the public interface of MPIR. It's only used for our asymptotically fast division, and for approximate division (which subsequently gets corrected in any actual division code anyway). Bill. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
