mersenneforum.org (https://www.mersenneforum.org/index.php)
-   And now for something completely different (https://www.mersenneforum.org/forumdisplay.php?f=119)

 Puzzle-Peter 2021-02-04 15:15

[QUOTE=Gelly;570844]

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[/CODE]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.
[/QUOTE]

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.

 paulunderwood 2021-02-04 19:48

@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 [c]top[/c] in a console. (I am running [C]nice -n -5[/C] on the main number and [C]nice -n 19[/C] on the subsidiary one. I am using all threads, but there is a slight impact on turbo.)

 Batalov 2021-02-04 20:38

1 Attachment(s)
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.

 paulunderwood 2021-02-24 06:38

[QUOTE=paulunderwood;568158]

Since ryanp is certifying M78737 cofactor, I'll have a stab at running M82939 cofactor (prp24948) at a low priority in parrallel with R49081,[/QUOTE]

[URL="https://primes.utm.edu/primes/page.php?id=132049"]M82939 cofactor is certified[/URL]

[URL="http://www.factordb.com/index.php?id=1100000000213099295"]FactorDB entry[/URL]

 paulunderwood 2021-03-15 16:58

Reserving:

[CODE]M86137 cofactor prp25896
M86371 cofactor prp25984
M87691 cofactor prp26371
E(11848)/(5*1582043) prp40792[/CODE]

 Gelly 2021-04-23 15:07

[QUOTE=Gelly;570844]
Meanwhile, in the interest of getting my irregular prime record back, I will be doing PRP28507, a cofactor of Bern(10264).[/QUOTE]

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.

 paulunderwood 2021-04-28 00:02

[QUOTE=Gelly;576620]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.[/QUOTE]

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.

 Batalov 2021-05-04 19:25

Asuncion & Allombert did the [URL="https://primes.utm.edu/primes/page.php?id=132290"]fib(130021)[/URL] proof,
but it remains to be seen if it was some [I]other[/I] ECPP or even a hybrid proof.
They are folks widely known in narrow circles (Pari/GP team, INRIA).

 paulunderwood 2021-05-04 19:41

[QUOTE=Batalov;577646]Asuncion & Allombert did the [URL="https://primes.utm.edu/primes/page.php?id=132290"]fib(130021)[/URL] proof,
but it remains to be seen if it was some [I]other[/I] ECPP or even a hybrid proof.
They are folks widely known in narrow circles (Pari/GP team, INRIA).[/QUOTE]

It will interesting to hear of what hardware they are using -- maybe a cluster?

 Batalov 2021-05-05 00:05

[QUOTE=wpolly;519486]I'll give a first call: I reserve Phi(32481,10) at 21600 digits.[/QUOTE]
It doesn't take 2 years to Primo such a small number.
Any news?

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

 paulunderwood 2021-05-05 02:09

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
<https://pari.math.u-bordeaux.fr/pub/bill/primecerts>
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 [url]https://www.plafrim.fr[/url])
"

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.[/QUOTE]

All times are UTC. The time now is 18:48.