I've removed the test large gap. Let's just trust that I've testing my mpz_prevprime patch sufficiently for that case and not both with checking it in.
The large change I'd like to submit is mpz_prevprime. The code is here: https://github.com/sethtroisi/libgmp/pull/10 It's ~320 lines changed and makes use of a macro to reuse the same inner loop with mpz_nextprime. To shrink this slightly you can first submit my refactor to t-nextprime https://github.com/sethtroisi/libgmp/pull/13 This moves a block of code out of main and into test_ref. It doesn't change code coverage at all, but conceptional clears the way for testing mpz_prevprime Thanks for the patience, Seth On Wed, Feb 5, 2020 at 1:47 PM Marco Bodrato <bodr...@mail.dm.unipi.it> wrote: > Ciao, > > Il 2020-02-05 00:59 Seth Troisi ha scritto: > > I got VERY VERY VERY lucky and found a prime gap > 2^15 with the 4th > > highest merit of ANY KNOW PRIME GAP. > > Great! > > > Given Marco's timing of 25 seconds (and a goal of say 3 seconds on > > that machine) the start prime would need to be ~~200 digits. > > >>> t...@gmplib.org (Torbjörn Granlund) writes: > >>>> We have tried to stick to a limit of 1 s on a reasonable current > >>>> computer. Most tests should use much less, if possible. > > I underline one word TG used: reasonable. Mine was not :-) > > I was only measuring how much the patch increases the time used by the > test. > > But I'm personally still not really understanding which feature is > tested by the patched code and not tested by the current code. > > Ĝis, > mCiao, > > Il 2020-02-05 00:59 Seth Troisi ha scritto: > > I got VERY VERY VERY lucky and found a prime gap > 2^15 with the 4th > > highest merit of ANY KNOW PRIME GAP. > > Great! > > > Given Marco's timing of 25 seconds (and a goal of say 3 seconds on > > that machine) the start prime would need to be ~~200 digits. > > >>> t...@gmplib.org (Torbjörn Granlund) writes: > >>>> We have tried to stick to a limit of 1 s on a reasonable current > >>>> computer. Most tests should use much less, if possible. > > I underline one word TG used: reasonable. Mine was not :-) > > I was only measuring how much the patch increases the time used by the > test. > > But I'm personally still not really understanding which feature is > tested by the patched code and not tested by the current code. > > Ĝis, > m > _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
