mpz_prevprime

[Seth Troisi]

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 <bodrato at 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.
>
> >>> tg at 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.
>
> >>> tg at 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
>