Re: The bug still remains in 2.16.2-beta

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Wed, Aug 21, 2024 at 07:18:29PM +0200, Bill Allombert wrote:

> On Fri, Aug 16, 2024 at 06:16:07PM -0700, Ilya Zakharevich wrote:
> > On Fri, Aug 16, 2024 at 01:07:52AM -0700, Ilya Zakharevich wrote:
> > > Oups, I got hit by the bug which I already reported earlier this year!
> > > It is just that older versions of gp/PARI report primelimit wrong:
> > > they cap it before the gap which is >255 — but lie in the diagnostic
> > > output (as if no capping happened).
> > 
> > It turns out the bug remains: AFAIU, the ACTUAL primelimit below is
> > 2^32, not 5e9 reported below!
> 
> Indeed there is a bug:
> 
> ./gp -p 8589934592
> ? 8589934592-precprime(8589934592)
> %1 = 4294967305
> (instead of 9).
> 
> ./gp -p  4294967311
> ? prime(203280222)
> %7 = 15
> (instead of 4294967357)

I fixed this bug, thanks for reporting it!

> In any case since primes are stored as 32bit values, the limit
> is 2^32.

Eventually, we could store primes as 64bit values and move the limit to 2^64.
However 2^32 is nearly 10 more than the previous limit of 436273009,
and the amount of memory required for the default value of 2^20 is 320kB

We decided to store each primes separately to allow for a faster implementation
of prime() and primepi().

Cheers,
Bill