rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7255
Credit: 42,729,227
RAC: 3
input
175000000000:P:1:51:257
607920 35218
llr2 gwnum 30.9
11920*51^35219+1 is not prime. RES64: 5326FBF23EE99827 Time : 12.728 sec.
llr3.8.21
607920*51^35218+1 is not prime. RES64: 5326FBF23EE99827. OLD64: 8C5E80CE11E6EA41 Time : 26.106 sec.
llr2 gwnum 30.4
11920*51^35219+1 is not prime. RES64: 5326FBF23EE99827 Time : 38.737 sec.
llr2 gwnum 29.8
607920*51^35218+1 is not prime. RES64: 5326FBF23EE99827 Time : 51.552 sec.
The app divides the number 607920 / 51 = 11920. The gwnum lib has a bug somewhere and the dev is informed.
At the moment only S51 is affected.
Base S51 will be stopped for the time being after 35-37k is done, the tests are correct with the divided numbers but primes cant be removed from the sievefile.
All affected tests must be convert to the correct values. This takes time.
/ 
Reply
Quote
The app divides the number 607920 / 51 = 11920. The gwnum lib has a bug somewhere and the dev is informed.
Isn't this exactly what it should do? If k=g*b^m, then testing g * b ^ (n + m) + c might be faster than testing k * b ^ n + c, because a shorter FFT length might be sufficient.
/ Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7255
Credit: 42,729,227
RAC: 3
The app divides the number 607920 / 51 = 11920. The gwnum lib has a bug somewhere and the dev is informed.
Isn't this exactly what it should do? If k=g*b^m, then testing g * b ^ (n + m) + c might be faster than testing k * b ^ n + c, because a shorter FFT length might be sufficient.
You are right, after some discussions we need pay attention on these cases.
/ Reply
Quote