mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > FactorDB

Reply
 
Thread Tools
Old 2015-09-12, 19:39   #12
pakaran
 
pakaran's Avatar
 
Aug 2002

24910 Posts
Default

Quote:
Originally Posted by pakaran View Post
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 is offline   Reply With Quote
Old 2015-09-17, 10:01   #13
pakaran
 
pakaran's Avatar
 
Aug 2002

3718 Posts
Default

And proving the 10 smallest PRPs (through 1701 digits). Should be done by the weekend, if not before.
pakaran is offline   Reply With Quote
Old 2015-09-17, 18:11   #14
pakaran
 
pakaran's Avatar
 
Aug 2002

3·83 Posts
Default

Quote:
Originally Posted by pakaran View Post
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.
pakaran is offline   Reply With Quote
Old 2015-09-26, 06:16   #15
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

1000010010102 Posts
Default

Quote:
Originally Posted by danaj View Post
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.
schickel is offline   Reply With Quote
Old 2015-09-28, 11:59   #16
pakaran
 
pakaran's Avatar
 
Aug 2002

3×83 Posts
Default

Quote:
Originally Posted by schickel View Post
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 is offline   Reply With Quote
Old 2015-09-30, 01:50   #17
pakaran
 
pakaran's Avatar
 
Aug 2002

3718 Posts
Default

Quote:
Originally Posted by pakaran View Post
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 is offline   Reply With Quote
Old 2015-09-30, 16:53   #18
pakaran
 
pakaran's Avatar
 
Aug 2002

3×83 Posts
Default

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 is offline   Reply With Quote
Old 2015-10-02, 00:24   #19
pakaran
 
pakaran's Avatar
 
Aug 2002

24910 Posts
Default

And taking all 28 below 2k digits. On my ancient laptop, above that starts taking a significant part of a day.
pakaran is offline   Reply With Quote
Old 2015-10-02, 11:30   #20
pakaran
 
pakaran's Avatar
 
Aug 2002

111110012 Posts
Default

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

There is now only a single PRP remaining below 3k digits.
pakaran is offline   Reply With Quote
Old 2015-10-02, 14:32   #21
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

1000010010102 Posts
Default

Quote:
Originally Posted by pakaran View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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
schickel is offline   Reply With Quote
Old 2015-10-03, 00:11   #22
pakaran
 
pakaran's Avatar
 
Aug 2002

F916 Posts
Default

Taking the (rather high) DB-id 1100000000700619218, with 3087 digits.
pakaran is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fixup Old Primo Certificate? wblipp FactorDB 1 2012-05-28 03:16
Invalid certificate? IvanP FactorDB 3 2012-05-11 12:17
Could Moore's law be purposely used for marketing purposes? jasong Science & Technology 10 2007-01-19 19:04
certificate of appreciation Unregistered Information & Answers 13 2004-04-28 06:24

All times are UTC. The time now is 04:09.

Mon Mar 8 04:09:19 UTC 2021 up 95 days, 20 mins, 0 users, load averages: 3.19, 2.99, 2.72

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.