Register FAQ Search Today's Posts Mark Forums Read

2021-02-04, 15:15   #45
Puzzle-Peter

Jun 2009

10101100012 Posts

Quote:
 Originally Posted by Gelly In the meantime, I have been meaning to (actually) prove the cofactor to Bern(8286), only to find what is the strangest return I have seen in a while from Primo: Code: [Candidate] Input=8286.in Output=prime-B422001C4C67B.out Status=Sorry, Primo cannot certify the candidate Failed in 26008 seconds. I genuinely am at a loss, as I have never ever seen this before. I checked my candidate against pfgw64, with all bases up to 15, and it seems to be really really PRP, so I guess Primo has its limitations. Will probably shoot an email to Marcel if no one here has ever seen it before.

The way Primo works is (very simply put) as follows: it looks for a number that is slightly smaller than the candidate (how much smaller is given as "gain" in bits) in such a way that the candidate is prime if the slightly smaller numer is prime. Then it repeats this process with smaller and smaller numbers until it reaches a very small number that is known to be prime.

Sometimes Primo cannot find such a smaller number. In such cases it backtracks, trying to find another helper number for the last step or the step before etc. I think backtracking is limited to 10 steps. If there are only dead ends, Primo is unably to prove the candidate prime. This happens usually at the beginning of a run when there is no or very little chance of backtracking. I don't know about the latest versions, but a few years ago, the largest number that Primo was guaranteed to be able to prove was less than a third (in terms of digits) of the largest numbers it was able to prove. So there is always a chance of failure and it's getting bigger with larger candidates.

Try contacting Marcel anyway as there might be another cause.

 2021-02-04, 19:48 #46 paulunderwood     Sep 2002 Database er0rr 1111000101112 Posts @Gelly You might find that altering the settings under "Menu" will get you further, most likely a proof. I cant's recall what it is called, but I think it goes up to "32". You most likely would have to start from the beginning. Also I am getting great thoughput by running two numbers at once. There are plenty of free cycles during phase 1. You can see what is happening by running top in a console. (I am running nice -n -5 on the main number and nice -n 19 on the subsidiary one. I am using all threads, but there is a slight impact on turbo.) Last fiddled with by paulunderwood on 2021-02-04 at 20:36
 2021-02-04, 20:38 #47 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·4,783 Posts I think there is also randomness in proof and/or user can induce the proof going different paths: change some options in settings. E.g. if you change the highlighted options, it will give up optimizing gain earlier or later, and you might pass the 1st test and then it will go forward. Attached Thumbnails
2021-02-24, 06:38   #48
paulunderwood

Sep 2002
Database er0rr

1111000101112 Posts

Quote:
 Originally Posted by paulunderwood Since ryanp is certifying M78737 cofactor, I'll have a stab at running M82939 cofactor (prp24948) at a low priority in parrallel with R49081,
M82939 cofactor is certified

FactorDB entry

Last fiddled with by paulunderwood on 2021-02-24 at 06:38

 2021-03-15, 16:58 #49 paulunderwood     Sep 2002 Database er0rr 3,863 Posts Reserving: Code: M86137 cofactor prp25896 M86371 cofactor prp25984 M87691 cofactor prp26371 E(11848)/(5*1582043) prp40792
2021-04-23, 15:07   #50
Gelly

May 2020

3·13 Posts

Quote:
 Originally Posted by Gelly Meanwhile, in the interest of getting my irregular prime record back, I will be doing PRP28507, a cofactor of Bern(10264).
Done! 6693424s (77.5 days). I'll first be tinkering with the cofactor of Bern(8286) (hopefully a month-ish at most), but after seeing Paul go hogwild on reservations, my next reservation is PRP32010, or M106391/286105171290931103.

2021-04-28, 00:02   #51
paulunderwood

Sep 2002
Database er0rr

3,863 Posts

Quote:
 Originally Posted by Gelly Done! 6693424s (77.5 days). I'll first be tinkering with the cofactor of Bern(8286) (hopefully a month-ish at most), but after seeing Paul go hogwild on reservations, my next reservation is PRP32010, or M106391/286105171290931103.
Nice one. I am looking forward to your first 30k+ digit certification.

Those 4 I reserved are running on a relatively slow Xeon Phi which has 256 threads. An instance of Primo often drops to one thread, So, in the long term I should get some nice throughput.

Last fiddled with by paulunderwood on 2021-04-28 at 00:07

 2021-05-04, 19:25 #52 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 225368 Posts Asuncion & Allombert did the fib(130021) proof, but it remains to be seen if it was some other ECPP or even a hybrid proof. They are folks widely known in narrow circles (Pari/GP team, INRIA).
2021-05-04, 19:41   #53
paulunderwood

Sep 2002
Database er0rr

3,863 Posts

Quote:
 Originally Posted by Batalov Asuncion & Allombert did the fib(130021) proof, but it remains to be seen if it was some other ECPP or even a hybrid proof. They are folks widely known in narrow circles (Pari/GP team, INRIA).
It will interesting to hear of what hardware they are using -- maybe a cluster?

2021-05-05, 00:05   #54
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

956610 Posts

Quote:
 Originally Posted by wpolly I'll give a first call: I reserve Phi(32481,10) at 21600 digits.
It doesn't take 2 years to Primo such a small number.
Any news?

I will queue to run Phi(70842,10) at 23613 digits.
And Phi(47468,10) at 23732 digits

2021-05-05, 02:09   #55
paulunderwood

Sep 2002
Database er0rr

3,863 Posts

Bill Allombert replied to my enquiry to him about the certiifcation of U(130021):

Quote:
 > Bill, > > congrats to you and Jared for the ECPP of U(130021). Thanks! Apology if I did not fill the form correctly. PARI/GP is not in the list of software, and I did not found where I could provide the relevant information. Finding out that Fibonacci numbers were to be denoted with U() already took some effort. > We were wondering what methods were used, what software and what > hardware too, and how long it took. Please let us know either by > replying to me or directly posting on: I used a modified version of PARI/GP primecert function, which was written by Jared during his internship at Bordeaux. The primality certificate is available in both PARI and Primo format at The PARI certificate can be checked with primecertisvalid in GP. Some of the changes I made are in PARI master branch, some other are not yet (because they would slowdown ecpp for smaller input). The main change is the parallelisation of the Cornacchia step. This computation was done as an experiment to find out what kind of changes were needed for large input. The computation was done with the pthread build of PARI on a dual AMD EPYC 7702 64-Core (so 128 total cores) and 1Tb of RAM. This is quite a fast system: to give an idea of the speed, checking the certificate with primecertisvalid() take 1h 4min of running time, (137h 36min total CPU time) I am required to state that " Experiments presented in this project were carried out using the PlaFRIM experimental testbed, supported by Inria, CNRS (LABRI and IMB), Université de Bordeaux, Bordeaux INP and Conseil Régional d’Aquitaine (see https://www.plafrim.fr) " I could only reserve this system for 72 contiguous hours, so I split the computation in 16 partial certificates. The running time was 743h, 29min, 59,167 ms, the total CPU time over all cores was 43386h, 1min, 9,709 ms.

 Similar Threads Thread Thread Starter Forum Replies Last Post Kosmaj Riesel Prime Search 706 2021-10-09 18:46 VBCurtis Riesel Prime Search 679 2021-10-09 17:33 Greenbank Octoproth Search 2 2007-12-26 09:58 Greenbank Octoproth Search 30 2006-02-09 00:33 Greenbank Octoproth Search 0 2006-01-25 13:41

All times are UTC. The time now is 09:08.

Thu Oct 21 09:08:48 UTC 2021 up 90 days, 3:37, 1 user, load averages: 0.85, 0.98, 1.14