Either way, I believe the test code alternately uses both uniformly distributed numbers and numbers with long strings of zeros and ones. Actually, I am embarrassed to say that I don't actually know if it allows the top bit to be zero, or not.
Bill. 2009/12/10 Dan Grayson <d...@math.uiuc.edu>: > I think the bug is activated only when the number of lead zero bits in > the denominator is in a certain narrow range, since that number > determines by how much to shift, but I haven't explored that > carefully. Therefore, for tests involving alignment, picking integers > with random bits is not good (if that's what you're doing), because > you'll only rarely get many lead zero bits. It would be better to > pick first the number of bits randomly. > > On Dec 10, 7:48 am, Bill Hart <goodwillh...@googlemail.com> wrote: > >> I'm a little surprised that this bug was not picked up during testing. >> The try program specifically tests for all memory alignment >> possibilities. I'll have to look into why it was not picked up. > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
