mersenneforum.org Certificate : For all indents and purposes
 Register FAQ Search Today's Posts Mark Forums Read

2015-09-12, 19:39   #12
pakaran

Aug 2002

3·83 Posts

Quote:
 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.

 2015-09-17, 10:01 #13 pakaran     Aug 2002 3·83 Posts And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.
2015-09-17, 18:11   #14
pakaran

Aug 2002

3·83 Posts

Quote:
 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.

2015-09-26, 06:16   #15
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2×1,061 Posts

Quote:
 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.

2015-09-28, 11:59   #16
pakaran

Aug 2002

3×83 Posts

Quote:
 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).

2015-09-30, 01:50   #17
pakaran

Aug 2002

3·83 Posts

Quote:
 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 )

 2015-09-30, 16:53 #18 pakaran     Aug 2002 3·83 Posts 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.
 2015-10-02, 00:24 #19 pakaran     Aug 2002 3·83 Posts And taking all 28 below 2k digits. On my ancient laptop, above that starts taking a significant part of a day.
 2015-10-02, 11:30 #20 pakaran     Aug 2002 3·83 Posts And done, though several, including the two biggest, got poached There is now only a single PRP remaining below 3k digits.
2015-10-02, 14:32   #21
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2×1,061 Posts

Quote:
 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....
Quote:
 Originally Posted by schickel While clearing the <3000 digit PRPs I came across this one at 2531 digits that is apparently not a PRP: Code: 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.
Quote:
 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.
Quote:
 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?
Quote:
 Originally Posted by schickel Well, well, well; speak of the devil: Code: 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".
Quote:
 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

 2015-10-03, 00:11 #22 pakaran     Aug 2002 111110012 Posts Taking the (rather high) DB-id 1100000000700619218, with 3087 digits.

 Similar Threads Thread Thread Starter Forum Replies Last Post wblipp FactorDB 1 2012-05-28 03:16 IvanP FactorDB 3 2012-05-11 12:17 jasong Science & Technology 10 2007-01-19 19:04 Unregistered Information & Answers 13 2004-04-28 06:24

All times are UTC. The time now is 20:11.

Fri Jan 22 20:11:30 UTC 2021 up 50 days, 16:22, 0 users, load averages: 1.50, 1.89, 2.01