[QUOTE=pakaran;410140]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 .[/QUOTE]
And done. 
And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.

[QUOTE=pakaran;410603]And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.[/QUOTE]
I stopped after the five smallest to focus on BOINC work. Feel free to prove anything still listed as PRP. 
[QUOTE=danaj;359779]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 21002300 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).[/QUOTE]
In another blatant case of necroposting, 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+alittle 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. :down: 
[QUOTE=schickel;411310]In another blatant case of necroposting, 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+alittle 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. :down:[/QUOTE]
I'm putting off BOINC work, so I can understand. I didn't realize anyone worked in DBid 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). 
[QUOTE=pakaran;411463]I'm putting off BOINC work, so I can understand.
I didn't realize anyone worked in DBid 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).[/QUOTE] 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 ) 
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. 
And taking all 28 below 2k digits. On my ancient laptop, above that starts taking a significant part of a day.

And done, though several, including the two biggest, got poached :evil:
There is now only a single PRP remaining below 3k digits. 
[QUOTE=pakaran;411823]And done, though several, including the two biggest, got poached :evil:
There is now only a single PRP remaining below 3k digits.[/QUOTE]Unfortunately, that one is not going to solve....[QUOTE=schickel;406484]While clearing the <3000 digit PRPs I came across this [URL="http://factordb.com/index.php?id=1100000000781996714"]one[/URL] at 2531 digits that is apparently [B]not[/B] 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[/code]The latest Primo 4.1.1 also reports this problem.[/QUOTE] [QUOTE=danaj;406508]Not a baseb pseudoprime for any b in 21000. I suspect whatever is doing the PRP testing is interpreting [FONT=Courier New]##[/FONT] differently, as described on the [URL="http://mersenneforum.org/showthread.php?t=16849&page=8"]Other Factordb Problems[/URL] page. Factordb inteprets [FONT=Courier New]n#[/FONT] as primorial (product of all primes below n) and [FONT=Courier New]n##[/FONT] 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 [FONT=Courier New]p(n)#[/FONT]), Probably a mismatch there, especially since if we give the expression to PFGW it will interpret it as [FONT=Courier New](776*776#+1)/92857[/FONT] which happens to be a proven prime, explaining why it keeps answering that it is PRP.[/QUOTE][QUOTE=schickel;406511]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] [QUOTE=schickel;406622]Well, well, well; speak of the devil: :grin:[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[/code]Unfortunately, it doesn't work. It accepted the two factors, but it didn't mark them as belonging to the "PRP". :sad: :no:[/QUOTE] [QUOTE=chris2be8;406646]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[/QUOTE] 
Taking the (rather high) DBid 1100000000700619218, with 3087 digits.

All times are UTC. The time now is 04:20. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.