mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   And now for something completely different (https://www.mersenneforum.org/forumdisplay.php?f=119)
-   -   Primo reservation thread (https://www.mersenneforum.org/showthread.php?t=24525)

wpolly 2019-06-18 10:27

Primo reservation thread
 
This thread is made following the suggestion of Paul Underwood in [URL="https://www.mersenneforum.org/showpost.php?p=519485&postcount=100"]this post[/URL], as a place of reserving large PRPs for ECPP testing.


I'll give a first call: I reserve Phi(32481,10) at 21600 digits.

paulunderwood 2019-08-01 21:27

From [url]https://www.mersenneforum.org/showpost.php?p=520442&postcount=310[/url]

I am reserving W35851

Done! [url]http://www.factordb.com/index.php?query=%282%5E35851%2B1%29%2F3%2F1184732147%2F1383891629171890065880777%2F54919454473787[/url]

Now doing: [url]http://factordb.com/index.php?id=1100000001336232261[/url] (23,451 digits) Done!

paulunderwood 2020-02-04 20:43

[url]https://www.mersenne.ca/exponent/78737[/url] PRP23654

sweety439 2020-02-17 16:10

Can someone reserve (51^4229-1)/50, (91^4421-1)/90 and 60^4663-59^4663?

paulunderwood 2020-02-26 10:40

[QUOTE=paulunderwood;536669][url]https://www.mersenne.ca/exponent/78737[/url] PRP23654[/QUOTE]

I am unreserving this number after a major catastrophic hardware failure -- the machine no longer posts.

It would be interesting to me for someone with a AMD 3990X to download the certificate for my recent 40k Primo proof from ellipsa.eu and run a verification on it. It took 15.5 hours on my now defunct Opteron class 48 cores at 2.2 GHz. A comparison would be very interesting.

Gelly 2020-05-26 00:54

[QUOTE=sweety439;537759]Can someone reserve (51^4229-1)/50, (91^4421-1)/90 and 60^4663-59^4663?[/QUOTE]

Already finished the first one, should be verified on FactorDB soonish! The other two are spun up on my system and should finish in a day or two. Hope this isn't crass to start work pre-reservation!

Gelly 2020-05-31 01:53

(51^4229-1)/50, (91^4421-1)/90 and 60^4663-59^4663 are all done! FactorDB finished with them and now they are recognized as prime.
[URL="http://factordb.com/index.php?id=1100000000651917018"]http://factordb.com/index.php?id=1100000000651917018[/URL]
[URL="http://factordb.com/index.php?id=1100000000685787852"]http://factordb.com/index.php?id=1100000000685787852[/URL]
[URL="http://factordb.com/index.php?id=1100000000467236538"]http://factordb.com/index.php?id=1100000000467236538[/URL]

After finishing that and presumably finishing my vanity prime test in a couple days, I'd like to reserve P = 3^45535+2 (PRP21726).

paulunderwood 2020-05-31 03:03

[QUOTE=Gelly;546843]

After finishing that and presumably finishing my vanity prime test in a couple days, I'd like to reserve P = 3^45535+2 (PRP21726).[/QUOTE]

Are you using a 32 core system?

Gelly 2020-06-23 04:57

[QUOTE=paulunderwood;546844]Are you using a 32 core system?[/QUOTE]

Yup! 3970x system, for everyone else on the forums who may be curious.

I finished 3^45535+2 in about 23 days, though there was a power outage, so precise numbers were lost, unfortunately. The certificate, once verified, will be [URL="http://factordb.com/index.php?id=1100000000213105555"]attached here![/URL]

I'll reserve 10^25333-2*10^5182-3 (PRP25333) because it looks silly and it'll force myself into 9th on ECPP.

Also...
[QUOTE=paulunderwood;538357]It would be interesting to me for someone with a AMD 3990X to download the certificate for my recent 40k Primo proof from ellipsa.eu and run a verification on it. It took 15.5 hours on my now defunct Opteron class 48 cores at 2.2 GHz. A comparison would be very interesting.[/QUOTE]

Running it with 3970x, it verified it in 37593s, or a touch less than 10.5 hours. I look forward to seeing results for a 3990x.

paulunderwood 2020-06-23 10:52

Congrats, Gelly, for the certification of 3^45535+2.

You might want to certify some t[URL="https://primes.utm.edu/top20/page.php?id=49"]op20 Mersnne co-factors[/URL]. The available ones are [URL="https://www.mersenne.ca/prp.php"]here[/URL]. If you are interested, I might have a backup of a partially done [URL="https://www.mersenne.ca/exponent/78737"]M78,737 [/URL]

Edit: I can't find a backup.

ryanp 2020-07-05 19:18

[QUOTE=paulunderwood;548863]Congrats, Gelly, for the certification of 3^45535+2.

You might want to certify some t[URL="https://primes.utm.edu/top20/page.php?id=49"]op20 Mersnne co-factors[/URL]. The available ones are [URL="https://www.mersenne.ca/prp.php"]here[/URL]. If you are interested, I might have a backup of a partially done [URL="https://www.mersenne.ca/exponent/78737"]M78,737 [/URL]

Edit: I can't find a backup.[/QUOTE]

I decided to fire up certification of M78737 with Primo, using 64 processes. Hopefully no one else is already running this!

The machine it's running on is a 3Ghz, 36-core/72-thread system. Anyone have a rough sense of how long this should take?

(Addendum: it would be great if Primo was open-source... I'd love to understand more about these "stk4321" processes it spawns. If I could farm these out to a cluster and then feed the results back in, presumably this could go a lot faster).

paulunderwood 2020-07-05 19:25

[QUOTE=ryanp;549836]I decided to fire up certification of M78737 with Primo, using 64 processes. Hopefully no one else is already running this!

The machine it's running on is a 3Ghz, 36-core/72-thread system. Anyone have a rough sense of how long this should take?

(Addendum: it would be great if Primo was open-source... I'd love to understand more about these "stk4321" processes it spawns. If I could farm these out to a cluster and then feed the results back in, presumably this could go a lot faster).[/QUOTE]

2-3 weeks, maybe a month.

Gelly 2020-08-07 22:40

[QUOTE=Gelly;548852]

I'll reserve 10^25333-2*10^5182-3 (PRP25333) because it looks silly and it'll force myself into 9th on ECPP.

[/QUOTE]

It's done! Precise count is 3934149s (45.5 days), although I had another decent power outage that had it not working for about a day. Seems like it saved the time stats correctly, though! Uploaded on FactorDB - though, it seems like it's having a hard time starting processing on it, so it's currently not there. Not worried, though - I'm sure it'll make it to processing eventually.

[QUOTE=paulunderwood;548863]
You might want to certify some t[URL="https://primes.utm.edu/top20/page.php?id=49"]op20 Mersnne co-factors[/URL]. The available ones are [URL="https://www.mersenne.ca/prp.php"]here[/URL].
[/QUOTE]

Probably more appropriate than silly-lookin PRPs. Since Ryan's got M78737, I will do the certification of M84211 (PRP25291). Good size, leaves the gap for M82939, in case anyone wants to cert a slightly smaller PRP, and I also just like how M84211 visually looks.

paulunderwood 2020-08-08 00:06

[QUOTE=Gelly;552874]It's done! Precise count is 3934149s (45.5 days), although I had another decent power outage that had it not working for about a day. Seems like it saved the time stats correctly, though! Uploaded on FactorDB - though, it seems like it's having a hard time starting processing on it, so it's currently not there. Not worried, though - I'm sure it'll make it to processing eventually.



Probably more appropriate than silly-lookin PRPs. Since Ryan's got M78737, I will do the certification of M84211 (PRP25291). Good size, leaves the gap for M82939, in case anyone wants to cert a slightly smaller PRP, and I also just like how M84211 visually looks.[/QUOTE]


Go to [url]https://primes.utm.edu/bios/[/url] and create a new prover account based on a "c" code for Primo if you don't already have one. Then you can submit your newly certified prime under the new code with the comment: ECPP, like this:

10^25333-2*10^5182-3 ECPP

For Mersenne cofactors the comment should be: Mersenne cofactor, ECPP

Also use sendspace or similar to send Marcel Martin a download link for the certificate and you will get a listing on his top20 Primo proofs page.

Congrats! :banana:

LaurV 2020-08-27 13:57

[QUOTE=Gelly;552874] and I also just like how M84211 visually looks.[/QUOTE]
Yeah, pretty huh? Lots of 1 in binary... :razz:

ryanp 2020-09-22 19:19

[QUOTE=ryanp;549836]I decided to fire up certification of M78737 with Primo, using 64 processes. Hopefully no one else is already running this![/QUOTE]

An update: the machine running this certification had to be restarted, and I forgot to fire up the job again. Running it again now, with 36 workers. It's currently at "Bits: 78188/78577" in phase 1.

Gelly 2020-09-25 12:17

[QUOTE=Gelly;552874] Since Ryan's got M78737, I will do the certification of M84211 (PRP25291). Good size, leaves the gap for M82939, in case anyone wants to cert a slightly smaller PRP, and I also just like how M84211 visually looks.[/QUOTE]

Done! 4132590s (47.8 days). Once Marcel puts it up and I submit to Prime Pages, it should be the largest Mersenne Cofactor proven prime by a fair bit.

For the time being, since I want to wait on my incoming Thermosyphon as a sweet threadripper cooler, I'll not do another reservation for a while yet.

paulunderwood 2020-09-25 12:49

[QUOTE=Gelly;557830]Done! 4132590s (47.8 days). Once Marcel puts it up and I submit to Prime Pages, it should be the largest Mersenne Cofactor proven prime by a fair bit.

For the time being, since I want to wait on my incoming Thermosyphon as a sweet threadripper cooler, I'll not do another reservation for a while yet.[/QUOTE]

:banana: Congrats for the proof of the M84211 cofactor.

paulunderwood 2020-09-28 03:57

[QUOTE=paulunderwood;557834]:banana: Congrats for the proof of the M84211 cofactor.[/QUOTE]

[URL="https://primes.utm.edu/primes/page.php?id=131278"]It is up[/URL].

sweety439 2020-10-08 21:29

Suggest these probable primes for the "proven" [URL="https://docs.google.com/document/d/e/2PACX-1vQMhZGxAX7Yuzx2q1xyKudcbWLhKlyzEOqmjDBRgTjJdguhMTORkHIOEZbq2-BMVswY9IYDNnWsnwkN/pub"]Sierpinski[/URL]/[URL="https://docs.google.com/document/d/e/2PACX-1vTb4hZ3-V6K6usszow7_EfYULqeJerDObsY9EUrycbtewwHbuPRy40OaP1Gftc9Mzes_NAalbF8cNyG/pub"]Riesel[/URL] conjectures, if the primality of these probable primes were proven, then these Sierpinski/Riesel conjectures would be completely proven.

S73: (14*73^21369+1)/3 (may be too large)
S105: (191*105^5045+1)/8
S256: (11*256^5702+1)/3

R7: (197*7^181761-1)/2 and (367*7^15118-1)/6 (may be too large)
R73: (79*73^9339-1)/6
R91: (27*91^5048-1)/2
R100: (133*100^5496-1)/33
R107: (3*107^4900-1)/2

Gelly 2020-11-01 17:58

Someone mentioned to me another list that is outdated in terms of compute power is the Unique Primes list, so I'll be proving Phi(79710,10) (PRP21248)

sweety439 2020-11-02 00:22

[QUOTE=Gelly;561841]Someone mentioned to me another list that is outdated in terms of compute power is the Unique Primes list, so I'll be proving Phi(79710,10) (PRP21248)[/QUOTE]

There is a much smaller PRP factor of Phi(n,10), (10^6881-1)/(10^983-1)/49141059632832877096172610809992897380296624365337454176129, see [URL="https://stdkmd.net/nrr/repunit/prpfactors.htm"]https://stdkmd.net/nrr/repunit/prpfactors.htm[/URL]

Batalov 2020-11-02 02:37

[QUOTE=Gelly;561841]... the [B]Unique Primes[/B] list, so I'll be proving Phi(79710,10) (PRP21248)[/QUOTE]

[QUOTE=sweety439;561890]There is a much smaller PRP factor of ...[/QUOTE]
...and is it a unique number?

VBCurtis 2020-11-02 06:54

[QUOTE=Batalov;561902]...and is it a unique number?[/QUOTE]

Sweety doesn't let knowledge or relevance get in the way of telling people what to do with their time. Shame, really.

Dr Sardonicus 2020-11-02 13:49

[QUOTE=Batalov;561902][QUOTE=Gelly;561841]... the [B]Unique Primes[/B] list, so I'll be proving Phi(79710,10) (PRP21248)[/QUOTE]

[QUOTE=sweety439;561890]There is a much smaller PRP factor of ...[/QUOTE]...and is it a unique number?[/QUOTE]
No. This is easily inferred from the latter post. The factor in the denominator is obviously larger than (10[sup]7[/sup] - 1)/9. We find that

[tex]\Phi_{6881}(10)\text{ has the prime factors 13763 and 3213467855281944242613907639214901656160438225853}[/tex]

in addition to the PRP cofactor. The decimal expansions of the reciprocals of these two primes have period 6881.

paulunderwood 2020-11-02 15:58

[QUOTE=sweety439;561890]There is a much smaller PRP factor of Phi(n,10), (10^6881-1)/(10^983-1)/49141059632832877096172610809992897380296624365337454176129, see [URL="https://stdkmd.net/nrr/repunit/prpfactors.htm"]https://stdkmd.net/nrr/repunit/prpfactors.htm[/URL][/QUOTE]

For one who is obsessed with all things small, why don't you do it yourself? If you have Win10 you can install Linux in WSL and run Primo. What is your excuse? :ermm:

Gelly 2020-11-23 22:11

[QUOTE=Gelly;561841]Someone mentioned to me another list that is outdated in terms of compute power is the Unique Primes list, so I'll be proving Phi(79710,10) (PRP21248)[/QUOTE]

Done! Took longer than it should have, as I'm running double duty on a bunch of silly projects with too few computers, but it's done. As an added bonus, this one managed to get onto FactorDB, so no need to rely on having it be a top 20 Primo result for proof!

Next project is a PRP22234 (thanks, Thomas Ritschel!), which will be the largest proven irregular prime by a wide margin once it's done.

paulunderwood 2020-12-25 02:11

I am 5.5 months into certifying R49081. Expect the result in August or September 2021 assuming all goes well. :xmastree:

Batalov 2020-12-25 04:46

I am [STRIKE]nearly[/STRIKE] done with a 'small' Euler irregular ([URL="https://primes.utm.edu/primes/page.php?id=131505"]21k digits[/URL]) and working on a new Bern irregular (26k digits).

Gelly 2021-01-03 05:55

[QUOTE=Gelly;564141]
Next project is a PRP22234 (thanks, Thomas Ritschel!), which will be the largest proven irregular prime by a wide margin once it's done.[/QUOTE]

Got the wrong one. I evidently don't understand how to order candidates in Primo right, so instead I proved 798*Bern(8766)/(487*4657*6468702182951641) (23743 digits).

Currently being verified by FactorDB and will post with a new proof code soon enough. It beats the old record by almost 10k digits and it was an accident. Figures, haha.

Next is the actual PRP I meant to work on, which didn't actually list the candidate, defeating the purpose of the "primo reservation" bit. The PRP is 348054*Bern(8286)/(103*409*1381*123997*217757687456069039) (22234 digits).

[QUOTE=paulunderwood;567283]I am 5.5 months into certifying R49081. Expect the result in August or September 2021 assuming all goes well. :xmastree:[/QUOTE]

I'm extremely excited to hear about how fast that is, considering how large the candidate is! I may have to splurge on a 3990x myself, assuming that's your current machine, or just wait until the next major development in thread technology or whatever.

[QUOTE=Batalov;567286]I am [STRIKE]nearly[/STRIKE] done with a 'small' Euler irregular ([URL="https://primes.utm.edu/primes/page.php?id=131505"]21k digits[/URL]) and working on a new Bern irregular (26k digits).[/QUOTE]

Beans. Looks like my Bern irregular record will be terribly ephemeral. Nice work!

Batalov 2021-01-03 06:30

1 Attachment(s)
Summarizing:[LIST][*]798*Bern(8766)/(487*4657*6468702182951641) ([URL="http://factordb.com/index.php?id=1100000002364864121"]23743 digits[/URL]) Done[*]348054*Bern(8286)/(103*409*1381*123997*217757687456069039) ([URL="http://factordb.com/index.php?id=1100000002228018702"]22234 digits[/URL]) Reserved; in progress ?[*]numerator(Bern(9702)) cofactor ([URL="http://factordb.com/index.php?id=1100000002198594541"]26709 digits[/URL]) Reserved; 60% done[/LIST]
Re: order: the candidates will be done in the order in which you shift-clicked. If you select/drag a range of numbers, then primo will "decide itself". Hint: always have the size estimates at hand and (as needed) convert them to bit-size and then quickly see that size in the Bits dialog window:

Batalov 2021-01-03 06:45

Btw, a few people asked before, how to estimate how far are you down the path of the proof. A number of years ago, I'd splined the runtimes to "Bits" size and the power slope was not quite "4" and not quite "5". (Probably due to backtracks. If descent was ideal, then one could expect nearly "4".)
I use "4.5".

That is: if the progress in bits is (using example shown above): 70889 / 88724, then the percent remaining work is :
[CODE]? (70889 / 88724) ^ 4.5
0.36426 \\ this much remaining, approximately
? 1 - %
0.63573 \\ this much done, approximately[/CODE]

Gelly 2021-01-03 06:52

[QUOTE=Batalov;568155][*]348054*Bern(8286)/(103*409*1381*123997*217757687456069039) ([URL="http://factordb.com/index.php?id=1100000002228018702"]22234 digits[/URL]) Reserved; in progress ?
[/QUOTE]

Yup! Using the formula you provided in the second post, it's 3.6% done.

I recall the split being between 4 and 5 being something you could determine using heuristic arguments - on Wikipedia, they give the big-O as definitely O(log(n)^(5+epsilon)), with some versions of heuristic arguments bringing it down to O(log(n)^(4+epsilon)).

Since Wikipedia is very wishy-washy about it, I would put it somewhere between those two estimates, giving what you found, 4.5.

Edit: Think you got your numbers backward - (80000/80000)^4.5 = 1, meaning 100% remaining, not 100% done. At least, when you read the number from Primo directly.

paulunderwood 2021-01-03 07:33

It would be a nice feature if Primo showed % done and an ETA.

Have you experimented with running more than one instance of Primo, maybe at different priorities? There are a lot of free cycles during phase 1.

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

Batalov 2021-01-03 08:09

There are pros and cons. Yes, you can run some other computations, but then (just my guess) primo master thread doesn't serve slaves with that share memory that it holds (that and queuing the spawned kids is its only work) all too well, and primo progress slows down disproportionally.

If you observed "top" then you can see mysterious parameters passed onto "stk*1" workers. I think the second to last parameter is a reference to its private offset into shared mem. They all borrow data from master by reference (master holds a couple Gb of RAM); the spawns are born small and then suddenly show 1.5g of RAM, too.

Ok, I'll tell you more. I once tried to distribute slaves across cluster. (I wrote wrappers that passed all parameters and managed quasi-queues.) But it was all in vain because they could not access memory of the master, and all quit.
[U]Conclusion[/U]: the 1st stage has to be done on one physical node (with shmem).

I was able to run 2nd stage faster (if you have many nodes), though it is tedious and easy to make a mistake. YOU'VE BEEN WARNED; if you don't have a firm hand - don't do it. And disclaimer: that was with old versions - pre 4.3, so all .t files were processed in order.

Here is the sketch of how:[LIST][*] keep in mind that what 2nd stage does is: it takes any 'uncooked' .t file, and cooks it, and writes it back. That is embarrassingly parallel and doesn't have any if/else branching.[*]have at least one .t file reprocessed in master node (it becomes smaller and its datestamp is newer than the .tmp file)*[*]clone the complete work folder to slave node[*]on the slave node: copy the finished .t [B]over[/B] half of the unfinished .t files (this will make the state of the "proof object" patently violated, but you will later only use [U]all other[/U] .t files, and send them back to master)[*]start another primo on the slave node.[*]the slave primo will skip over half of the "fake-done" .t files (they have the 'done' bit set in their header) and will do all others. (and then it will fail and will probably delete all temp files, so you have to babysit and stop it before it is fully done.)[*]At that time master will still be busy. Stop it and transfer only the "really done" .t files from the slave, overwrite the corresponding undone .t files[*]restart master primo [*]it will finish the half that is its own and will find all others already done and will combine all .t files into the .out file.[*][U]Caution[/U]: one wrong move and you shot yourself in the foot**. Have a legitimate backup of non-faked native primo work folder.[/LIST]
[B]TL;DR version[/B]: it is not worth the saved time. Don't do it.
____
* perhaps a cooked .t file can be taken frozen for some previously done project. Never tried. Who knows - maybe primo master does light sanity check on the cooked .t file? maybe it only reads its magic header (several bytes). Maybe it checks a few more things and then it will reject a foreign .t file.

** there was a comparative list of programming languages; what happens when the programmer shoots himself in the foot. There was one language where the foot then explodes. That is similar to what will happen here. :rolleyes:

paulunderwood 2021-01-03 08:23

Hmm, I have just created a second Primo folder and am running M-cofactor at niceness 19. I have 128 threads after all. But you seem to be right about top -- I'll monitor the situation for a week or two,

Batalov 2021-01-03 08:37

What Primo does is it takes "an onion" and peels layers, down to the inner core. (Well for the onion, the volume is R^3, but this is a nearly good analogy. Think of it as if volume formula was R^4.5.)
So, here is a neat rule of thumb: if you peel off only [B]1/7[/B] of the diameter, you have done half of the job.

The reverse is true:
Q: suppose you wanted to do a series of projects each twice as hard as the last.
A: Recipe to achieve that: always add +1/6 of the size of the last number.

In "Bits", primo shows how small the current onion has become. It doesn't matter for primo if you are just beginning a 70,000-bit number or if you peeled your 88,000-bit number to a 70,000-bit intermediate number. If I started right now another 70,000-bit number on another sibling machine, it would progress nearly exactly like this number in progress.

Gelly 2021-02-02 17:32

[QUOTE=Gelly;568152]Got the wrong one. I evidently don't understand how to order candidates in Primo right, so instead I proved 798*Bern(8766)/(487*4657*6468702182951641) (23743 digits).
[/QUOTE]

i did it twice.

i proved the bern(8766) with ecpp twice.

it'll be a bit before i get the cofactor of bern(8286).

ughhhhhhh.

paulunderwood 2021-02-02 18:10

So you submitted a wrong entry to the top5000 at this time? Oops

Gelly 2021-02-02 23:14

[QUOTE=paulunderwood;570748]So you submitted a wrong entry to the top5000 at this time? Oops[/QUOTE]

mhm. i imagine it's not a super big deal, but i don't know how to let caldwell know based on the page.

Batalov 2021-02-03 00:46

I had a couple of mishaps with Chris C, because over the years I'd submitted over 600 primes and many in very different formats. (I tried to get at least one entry in each archivable category, unless totally unfeasible). I remember that one was an irregular and E() function produces half positive and half negative values, so I submitted an entry without leading '-' so he rejected it as a negative. A few times I had simply had a typo in some formula.

His usual decision is to delete entry (and not reuse that id), but advise user to submit again corrected entry later. He typically declines to manually edit entries by direct access to the database (which he probably could). It is a robust approach to editing: "edit" = "delete" + "resubmit".

You can write using his email at the bottom of every page - he responds quite quickly (except he takes weekends properly, - he probably could read emails but he replies on next weekday). or you can add [C]&comment=1[/C] to the URL and write a comment.

Batalov 2021-02-03 20:32

Apparently [URL="https://mersenneforum.org/member.php?u=13637"]Alfred[/URL] proved a [URL="https://primes.utm.edu/primes/page.php?id=131701"]ranked #8 ECPP prime[/URL], too. Congrats!

(10[SUP]27669[/SUP]+7)/8313493832818655929448065598763458531111

Alfred 2021-02-03 20:51

Thank you - for your congrats and your correct attribution.

Gelly 2021-02-04 13:49

[QUOTE=Alfred;570808]Thank you - for your congrats and your correct attribution.[/QUOTE]

Wow, that's a good one. Nice work!

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.

Meanwhile, in the interest of getting my irregular prime record back, I will be doing PRP28507, a cofactor of Bern(10264).

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]

Cybertronic 2021-05-26 09:19

smallest tuplets certifications
 
Hello folk!
Have anyone of you time to certificate these numbers with primo and then make an upload to factordb.com?


prime:
[FONT=Times New Roman, serif][SIZE=2]10^7999+35887[/SIZE][/FONT]
[FONT=Times New Roman, serif][SIZE=2]10^8999+3541[/SIZE][/FONT]

twins:
7000 digits : 10^6999+ 151203769+d, d=0,2
8000 digits : 10^7999+ 439617139+d, d=0,2
9000 digits : 10^8999+ 13215871+d, d=0,2
10000 digits : 10^9999+2421018649+d, d=0,2 found by Dirk Augustin (2010)


Let me know !


best wishes
Norman

Cybertronic 2021-05-28 10:27

I take
10^9999+2421018649 and 10^9999+2421018651

Gelly 2021-05-28 15:42

[QUOTE=Cybertronic;579112]Hello folk!
Have anyone of you time to certificate these numbers with primo and then make an upload to factordb.com?


prime:
[FONT=Times New Roman, serif][SIZE=2]10^7999+35887[/SIZE][/FONT]
[FONT=Times New Roman, serif][SIZE=2]10^8999+3541[/SIZE][/FONT]

twins:
7000 digits : 10^6999+ 151203769+d, d=0,2
8000 digits : 10^7999+ 439617139+d, d=0,2
9000 digits : 10^8999+ 13215871+d, d=0,2
10000 digits : 10^9999+2421018649+d, d=0,2 found by Dirk Augustin (2010)


Let me know !


best wishes
Norman[/QUOTE]

I've taken Halebardo off of my current reservation to take the rest of your primes, which, to clarify, are:

10^7999+35887
10^8999+3541

10^6999+151203769+d, d=0,2
10^7999+439617139+d, d=0,2
10^8999+13215871+d, d=0,2

Should be brief enough and will upload all to factordb.

paulunderwood 2021-05-28 16:09

The first two should be "prime", according to Norman. Maybe the certificates are not easily available.

Cybertronic 2021-05-28 17:11

1 Attachment(s)
[QUOTE=Gelly;579319]I've taken Halebardo off of my current reservation to take the rest of your primes, which, to clarify, are:

10^7999+35887
10^8999+3541

10^6999+151203769+d, d=0,2
10^7999+439617139+d, d=0,2
10^8999+13215871+d, d=0,2

Should be brief enough and will upload all to factordb.[/QUOTE]


Gelly - super,thanks !
Should I mention your real name in my "smallest prime k-tuplet"-pdf document or not ? Yes, what is your name ?


Here the actual status:

Cybertronic 2021-05-28 17:16

[QUOTE=paulunderwood;579326]The first two should be "prime", according to Norman. Maybe the certificates are not easily available.[/QUOTE]


Which two,Paul?

paulunderwood 2021-05-28 17:24

[QUOTE=Cybertronic;579335]Which two,Paul?[/QUOTE]

[quote]prime:
10^7999+35887
10^8999+3541
[/quote]

Maybe you meant "PRP" :smile:

Cybertronic 2021-05-28 17:36

@Paul
Indeed :smile:

Cybertronic 2021-05-29 07:01

@[URL="https://www.mersenneforum.org/member.php?u=15009"][COLOR=teal]sweety439[/COLOR][/URL]


You must know, double the number of digits you will test with primo, so the runningtime will be 16 times longer (or more).


jump from 31000 to 40000 digit , about (40000/31000)^4 = 3.
Example: You need 6 months to certify a 31000 number, than you need 12 months to fall down from 40000 to 31000 digits in Phase 1 (Primo)


(estimated)


137h for a 27000 digit numer is UNBELIEVABLE fast !


10 years ago,the old primo version 3.0.9 for windows and on a singlecore needed for 10000 digits (~limit) more than 10000h on a 3 GHz Phenom...40.000 digit ~ (double the digits was 22 times longer) you need 5 million hours or 600 years.

Gelly 2021-06-01 01:29

[QUOTE=Cybertronic;579334]Gelly - super,thanks !
Should I mention your real name in my "smallest prime k-tuplet"-pdf document or not ? Yes, what is your name ?


Here the actual status:[/QUOTE]

Sure! All the certificates are uploaded to factorDB, and my name should be listed as the certifier for them.

Cybertronic 2021-06-01 05:11

@Gelly


That was fast, thank you !
This week, the "smallest gigantic twin" also done.


best wishes



(BTW, I see the name)

Cybertronic 2021-06-01 13:01

Is Bern(8286) now proven ?


I asked, maybe we should set lower parameters (dd=3000,not dd=11000) and get another way earlier...

Cybertronic 2021-06-03 20:20

10000 digit twins
 
So folk, the certifications are done and uploaded to factordb.com

10^9999+2421018649+d,d=0,2 are the smallest gigantic PROVEN twin primes.
Maybe it should be mention in wikipedia ?!

Numbers was found first by Dirk Augustin in 2010 and now proven primes by Norman Luhn.

:thumbs-up:

Cybertronic 2021-06-05 12:51

smallest 20000-digit twins
 
Here are maybe more Primo jobs ?!

Even I found the smallest 20000 digit twin PRPs.

[COLOR=Red][B]10^19999+1514722609+d,d=0,2[/B][/COLOR]

Smallest 20000-digit PRP is 10^19999+[FONT=Times New Roman, serif][SIZE=2]110949 [I]/ found by Patrick De Geest[/I][/SIZE][/FONT]


best,
Norman

paulunderwood 2021-06-05 14:18

[QUOTE=Cybertronic;580012]Here are maybe more Primo jobs ?!

Even I found the smallest 20000 digit twin PRPs.

[COLOR=Red][B]10^19999+1514722609+d,d=0,2[/B][/COLOR]

Smallest 20000-digit PRP is 10^19999+[FONT=Times New Roman, serif][SIZE=2]110949 [I]/ found by Patrick De Geest[/I][/SIZE][/FONT]


best,
Norman[/QUOTE]

These are not "top20" special forms at the PrimePages. They would take you 16 times as long each as the 10k digit primes you certified.

Cybertronic 2021-06-05 14:38

>These are not "top20" special forms at the PrimePages. They would take you 16 times as long each as the 10k digit primes you certified.

I know this, but it is maybe for a TR "a quick bit" between breakfast and lunch:grin:


This twin is just listed as PRP in my project file.

Batalov 2021-06-14 22:15

:direction:
Unrelated posts are split to separate thread - [URL="https://mersenneforum.org/showthread.php?t=26905"]"Education of Eliza Doolittle"[/URL]

Gelly 2021-07-09 04:44

[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]

i relinquish my reservation for the time being. do feel free to claim it, as my machine is problematic as of late.

Batalov 2021-08-04 07:48

Facq, Asuncion & Allombert are now exercising an alternative ECPP implementation with Pari/MPI.
[URL="https://primes.utm.edu/primes/page.php?id=132583"]Decent sizes, good p.o.c.[/URL]

sweety439 2021-08-04 09:18

[QUOTE=Batalov;584780]Facq, Asuncion & Allombert are now exercising an alternative ECPP implementation with Pari/MPI.
[URL="https://primes.utm.edu/primes/page.php?id=132583"]Decent sizes, good p.o.c.[/URL][/QUOTE]

Nice!!! (2^95369+1)/3 is now proven prime!!! [URL="https://mersenneforum.org/showpost.php?p=579745&postcount=3"]https://mersenneforum.org/showpost.php?p=579745&postcount=3[/URL]

sweety439 2021-08-09 14:31

Why (2^95369+1)/3 is not shown in [URL="http://www.ellipsa.eu/public/primo/top20.html"]http://www.ellipsa.eu/public/primo/top20.html[/URL]? It has been proven to be prime, see [URL="https://primes.utm.edu/top20/page.php?id=67"]https://primes.utm.edu/top20/page.php?id=67[/URL]

paulunderwood 2021-08-09 16:00

Der, it was not proved with Primo but with Pari/MPI. ^^^ See above.

sweety439 2021-08-09 16:04

[QUOTE=paulunderwood;585265]Der, it was not proved with Primo but with Pari/MPI. ^^^ See above.[/QUOTE]

But it is shown in [URL="https://primes.utm.edu/top20/page.php?id=27"]https://primes.utm.edu/top20/page.php?id=27[/URL]

paulunderwood 2021-08-09 16:11

Yes and so it should be. It is an ECPP proven prime big enough to get into the top20. Marcel Martin's Primo does not have a monopoly on such proofs. Wise up,

Dr Sardonicus 2021-08-10 12:30

[tex]\text{Primo }\subset\text{ ECPP}[/tex]

[tex]\text{ECPP }\not\subset\text{ Primo}[/tex]

paulunderwood 2021-09-18 20:02

Congrats to Facq, Asuncion and Allombert for breaking the ECPP 30k barrier with the [URL="https://primes.utm.edu/primes/page.php?id=132721"]proof of U(148091)[/URL] -- Fibonacci Number with 30,949 decimal digits.

:banana:

Gelly 2021-11-28 03:51

[QUOTE=Gelly;582863]i relinquish my reservation for the time being. do feel free to claim it, as my machine is problematic as of late.[/QUOTE]

looks like no one claimed it, and i've de-crufted my machine and set up, so i'm working on this candidate again!!

paulunderwood 2021-11-28 07:50

Welcome back to the fold.

[QUOTE=paulunderwood;573777]Reserving:

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

I should be continuing these shortly into the new year :devil:

I can do the Mersenne cofactor Ryan reserved about a year ago too. Ryan?


All times are UTC. The time now is 12:50.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.