Certificate : For all indents and purposes

[pakaran]

Originally Posted by pakaran

Since this thread seems inactive, and the number in question has sat for at least several days, I am currently proving the PRP2000 with database ID 1100000000802455607 .

And done.

[pakaran]

And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.

[pakaran]

Originally Posted by pakaran

And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.

I stopped after the five smallest to focus on BOINC work. Feel free to prove anything still listed as PRP.

[schickel]

Originally Posted by danaj

I've seen a lot of certificates being processed for RichD and RobertS over the last month or so. A month or two ago I was doing some small ones as well as 2100-2300 digit ones from the list, but I've lately been working on some prime gaps up in the 6000 digit range instead, especially as anything under 2100 digits now gets handled within an hour or so, making my proofs usually wasted (albeit for really small amounts of CPU time).

In another blatant case of necro-posting, here's a way to clear out some deadwood. I take the first 500 PRPs starting at 300 digits and then work on the first 1/4 of the list or so. The files are in "FactorDB ID" order, so the ones at the top of the list are the oldest ones. They seem to mostly be in the 3000+a-little range right now, and these keep my PC busy. (I'm really kind of just putting off starting work on my factoring queue; smallest job is 152 digits right now.

[pakaran]

Originally Posted by schickel

In another blatant case of necro-posting, here's a way to clear out some deadwood. I take the first 500 PRPs starting at 300 digits and then work on the first 1/4 of the list or so. The files are in "FactorDB ID" order, so the ones at the top of the list are the oldest ones. They seem to mostly be in the 3000+a-little range right now, and these keep my PC busy. (I'm really kind of just putting off starting work on my factoring queue; smallest job is 152 digits right now.

I'm putting off BOINC work, so I can understand.

I didn't realize anyone worked in DB-id order; I've usually gone by file size (digits) order. I should have posted an explicit reservation, but figured there were enough numbers ahead of where I was to serve as "canaries in the coal mine".

I'm currently working on ID 1100000000328403064, (2^10613*75+1)/145019, with 3192 digits, and almost done with Phase 1 (currently at 7445 digits, should be done with Phase 1 today, and overall, at the latest, when I get home from work Tuesday evening).

I'm very impressed with the size of the PRP backlog (5 numbers under 3k digits as I write this, only one over 1205 digits).

[pakaran]

Originally Posted by pakaran

I'm putting off BOINC work, so I can understand.

I didn't realize anyone worked in DB-id order; I've usually gone by file size (digits) order. I should have posted an explicit reservation, but figured there were enough numbers ahead of where I was to serve as "canaries in the coal mine".

I'm currently working on ID 1100000000328403064, (2^10613*75+1)/145019, with 3192 digits, and almost done with Phase 1 (currently at 7445 digits, should be done with Phase 1 today, and overall, at the latest, when I get home from work Tuesday evening).

I'm very impressed with the size of the PRP backlog (5 numbers under 3k digits as I write this, only one over 1205 digits).

Done, though I expect the cert verification might take an hour or two. I'm now doing the 47 PRPs with under 1500 digits (my, they grow fast XD )

[pakaran]

Did all 47. Now taking DBID's 1100000000803680471 and 1100000000803682766, 1849 and 2161 digits.

If there's a better place for these reservations, by all means let me know.

[pakaran]

And taking all 28 below 2k digits. On my ancient laptop, above that starts taking a significant part of a day.

[pakaran]

And done, though several, including the two biggest, got poached

There is now only a single PRP remaining below 3k digits.

[schickel]

Originally Posted by pakaran

And done, though several, including the two biggest, got poached

There is now only a single PRP remaining below 3k digits.

Unfortunately, that one is not going to solve....

Originally Posted by schickel

While clearing the <3000 digit PRPs I came across this one at 2531 digits that is apparently not a PRP:

Version=3.0.9
WebSite=http://www.ellipsa.eu/
Task=Certification
ID=B3A3C031BF491
Created=07/25/2015 02:29:23 PM

[Common]
Path=C:\aliquot\Primo\work\
Selected=1
Processed=1
Certified=0
Candidate #1=Aborted, 0.00s

[Candidate #1]
Input=primo_1100000000781996714.in
Status=Candidate not strong pseudoprime to the base 2

The latest Primo 4.1.1 also reports this problem.

Originally Posted by danaj

Not a base-b pseudoprime for any b in 2-1000. I suspect whatever is doing the PRP testing is interpreting ## differently, as described on the Other Factordb Problems page. Factordb inteprets n# as primorial (product of all primes below n) and n## as pn_primorial (product of the first n primes = p_n #). PFGW interprets it differently (as far as I can tell, adding more # symbols beyond the first means nothing -- to get pn_primorial one uses p(n)#), Probably a mismatch there, especially since if we give the expression to PFGW it will interpret it as (776*776#+1)/92857 which happens to be a proven prime, explaining why it keeps answering that it is PRP.

Originally Posted by schickel

Darn it, then. I wanted to clear out everything less than 3000 digits, but it looks like there's going to one lone holdout.

What are the chances that a factor could be found and mark this particular number composite?

Originally Posted by schickel

Well, well, well; speak of the devil:

Using B1=3000000, B2=4016636513, polynomial Dickson(6), sigma=812894513
Step 1 took 7453019ms
Step 2 took 937321ms
********** Factor found in step 2: 3520514800699633460823911989
Found probable prime factor of 28 digits: 3520514800699633460823911989
Composite cofactor 24161566278972550168408072730476970270476506749746082631557024528395695782803180302528901974928792885843370994742546253269566191389510670086924201474323882638243272173133991807101066434945347589538453777932339535482149759390471307807968861772331584750143338558511366322783128808270090099618922033959948365965629440705821579473922412910166602416335093363891961621126854467819583799664849144832117400117073353378200458944117620403510205128014387588665382985138713846871522931764536280956167028061636398258999495413574237206865765450810276151064676931192134907232483157481157399849344344582879933388316958978343865266809301614535675920027605216864618745186933336761647508502311235301585740503865029892543865819795996999407103301445253186643736704427289340813496113280780306147234760035172202082510475653167315028615806150490505538734359120212827809073207378884803010753947876397592109025128579782912615015916326494283948595396723278341576806783816638865671808809059992810380613449439059055859082806707098680516929491648459108165839627544142122381913130807019058016559735444773711331151212109972526013084986580194545721321205046034160237388062940244840886695459253044179885922311194591936130792509180070888550608961996353688750803470928312640926055381429757257092145039908251169784522739155321874921647643952899105386398973109508642324423968667082678908498688824064056127707624704173116945707364186087146816630508704039613197077417327647311305789295169796969410427693084849675496242888052810460495111396509364639918807958503766386601806357500768745804894627418957949730056497988175730693991374100821738942826145199946546843414472497928700233431919366424515219106447954692536321065176993725415368743771365746873209620597533896768121799899924748720886385620392061119914467821536322499655907453218983871830172444007957875127142412773964243730748986971452929937201275845708811715639505216097748970282331896090384679630642845255077900316829736554123264865108550135976458966451810796154771122939889096533135610807051003754109921064624260361019832246872168646172491233363953874520707710003582405755793957808153409420439598023294713567809953743591989935898064596902973996382880492227661789713162658746420683201707105843604621272107043734947668423774968416500681536033798057633373953966620607158525462543925766704083421012418800231819176046496240456926478224477708601040508925387371836687606367382424344627871317474599433393599081928397742231769155425735912076830612946936948642557382532592054798309878465183739056917 has 2504 digits
Using B1=3000000, B2=4016636513, polynomial Dickson(6), sigma=4288230846
Step 1 took 7366145ms
Step 2 took 942454ms
Using B1=3000000, B2=4016636513, polynomial Dickson(6), sigma=1744904676

Unfortunately, it doesn't work. It accepted the two factors, but it didn't mark them as belonging to the "PRP".

Originally Posted by chris2be8

My first thought was to click the (show) link to get the decimal expansion of it and check that ECM and Primo are working on the same number as factordb.

Then I tried experimenting with that approach. bc says that the decimal expansion mod 3520514800699633460823911989 is zero. And when I put (776*776##+1)/92857/3520514800699633460823911989 into factordb it shows a composite matching the cofactor schickel found. So I think factordb is confused, it knows of the factor of the PRP but still thinks it's PRP.

I think this needs SYD to act.

Chris

[pakaran]

Taking the (rather high) DB-id 1100000000700619218, with 3087 digits.