Re: primelimit and forprime()

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

On Sun, Jan 07, 2024 at 10:20:02AM -0800, Ilya Zakharevich wrote:
>   P.S.  This is somewhat similar to what would happen if
>         • the advantage of sieving-on-the-fly gradually disappears,
>   	    and it has no advantage over nextprime() at some moment;
> 	  • gp/PARI knows about this, and switches to the nextprime()
>   	    after a certain threshold;
>   	  • However, the threshold is hardwired into gp/PARI, and its
>   	    value is way off for my computer.

I bisected where the switch happens (near a huge number below; compare
with my bug report on a related segfault in
     https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=2520
), and guessed what is the reason for this:

  (16:36) gp > ppp=sqrtint(190334138131456478)
  %2752 = 436273008
  (16:38) gp > -(ppp-(ppp=nextprime(ppp+1)))
  %2753 = 1
  (16:38) gp > -(ppp-(ppp=nextprime(ppp+1)))
  %2754 = 282

       *** Observe the prime gap which is larger than 255. ***

So it seems that:

  • When removing (my) code for handling arbitrarily large prime limits
    an (off by one?) bug was introduced. — This leads to the segfault
    mentioned above.
    
  • It seems that this removal leads to requests for large primelimit
    being (silently??!!) ignored, and — instead — “the maximal prime
    before a prime gap >255” (as above) is used. 

  • So while I spent a few hours debugging WHY prime limits like 4e9
    behave unexpectedly, under the hood gp/PARI was all the time
    SILENTLY using the primelimit of about 436e6.

  • There is no code to skip sieving above about 2e16 — on my machine
    this is the break-even point between sieving and nextprime().

Thanks,
Ilya

  P.S.  I’m at a loss of words at silent mangling of command-line options…