mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   FactorDB (https://www.mersenneforum.org/forumdisplay.php?f=94)
-   -   Certificate : For all indents and purposes (https://www.mersenneforum.org/showthread.php?t=18308)

firejuggler 2013-06-17 18:16

Certificate : For all indents and purposes
 
So far, we have
[LIST][*]Firejuggler working on anything below 1500 digits[*]Andi_HB working on [URL="http://mersenneforum.org/showpost.php?p=344090&postcount=6"]1975 digits[/URL][*]Puzzle-Peter working from [URL="http://mersenneforum.org/showpost.php?p=359742&postcount=8"]around 3000 + [/URL] digits[*]MyDogBuster working backward on 3000 digits and below[/LIST]
NOTE : (776*776##+1)/92857 is shown as PRP, it is , however composite.

MyDogBuster 2013-06-17 18:36

Nice job. Now if they would only make you a moderator and allow you to move the post to first in the thread, we would be in business.

firejuggler 2013-06-17 18:46

Just on this thread then. I make enough bad pun in real life.

Batalov 2013-06-17 18:50

"Porpoise"?

Are you from Brighton Beach? ;-)

firejuggler 2013-06-17 18:59

No, I was inspired by
[url]http://www.wastedtalent.ca/comic/phocoena-intensus[/url]

Andi_HB 2013-06-17 20:05

I`m doing the 1975 digit PRP now.

Puzzle-Peter 2013-06-22 04:41

Half of my range is gone, so I have to move it. I'll finish off 1996-2000, then work upward from there plus any new PRPs "behind my back" of 2000+ digits. I'll ignore anything that pops up below 2000.

Due to my setup that makes me download new work before finishing the last range, I am often active two or three thousand PRPs above my trailing edge to avoid overlap. ATM that means only a few digits but after the bulge (ending at 2031 digits) it's quite a lot. It will be a while until then though.

Puzzle-Peter 2013-11-18 20:19

While I was busy in real life, somebody did a lot of work and actually finished off the bulge, continuing upwards as it seems. To avoid stepping on each others toes, I'll move up close to 3000 digits as Ian does not seem to be hyperactive atm.

Let's see if we can really empty the "distribution of PRPs" page...

firejuggler 2013-11-18 21:43

editted first post

danaj 2013-11-19 07:43

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

pakaran 2015-09-12 10:55

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 .

pakaran 2015-09-12 19:39

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

pakaran 2015-09-17 10:01

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

pakaran 2015-09-17 18:11

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

schickel 2015-09-26 06:16

[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 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).[/QUOTE]
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. :down:

pakaran 2015-09-28 11:59

[QUOTE=schickel;411310]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. :down:[/QUOTE]

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 2015-09-30 01:50

[QUOTE=pakaran;411463]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).[/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 )

pakaran 2015-09-30 16:53

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 2015-10-02 00:24

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

pakaran 2015-10-02 11:30

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

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

schickel 2015-10-02 14:32

[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 base-b pseudoprime for any b in 2-1000. 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]

pakaran 2015-10-03 00:11

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

pakaran 2015-10-07 00:51

Taking another high DBID, 1100000000684707374 with 3099 digits.

pakaran 2015-10-10 19:19

Taking all current sub3k PRPs, including the 2346 digit.

pakaran 2015-10-10 23:01

And also taking the 90+ 3xx digit numbers that showed up for some reason. Those should be done within an hour.

pakaran 2015-10-11 01:13

...if more hadn't shown up. I still plan to get everything under 3k digits, besides the one freak, done before I get to sleep tonight.

pakaran 2015-10-11 14:07

And again taking the low list (including six numbers in the 12xx digit range)

pakaran 2015-10-11 18:19

And again (including a 1270 digit number).

pakaran 2015-10-11 20:12

I'm done for now. While this is my last comment, I hold no reservations.

firejuggler 2015-10-11 21:31

thank you for your hard work. Unfortunatly, new one appear almost hourly/daily, so it is a task without end.

pakaran 2015-10-11 23:06

Indeed.

pakaran 2015-10-12 01:37

And taking another 32 3xx digit numbers. It really doesn't help matters that the asymptotics are so heavily on the side of the PRP finders, even MORE so if they're working in a range large enough to need a thousand or so tests per PRP.

pakaran 2015-10-13 01:39

And, again, taking everything under 3k digits, including two of 2917.

pakaran 2015-10-13 02:31

Now caught up to 1200 digits (though both verification workers are busy with larger numbers). I am now working on the following:

[CODE]1100000000804064323 6106991767...83 1214
1100000000804080571 (2^4423-2^4277*3-2)/30 1330
1100000000804065308 2^4423-2^757*3-1 1332
1100000000804065548 2^4423-2^1205*3-1 1332
1100000000804065560 2^9689-2^1828*3-1 2917
1100000000804065535 2^9689-2^202*3-1 2917
[/CODE]

paulunderwood 2015-10-13 09:24

[QUOTE=pakaran;412541]
1100000000804065548 2^4423-2^1205*3-1 1332
[/QUOTE]

[code]
./pfgw64 -V -i -tc -q"2^4423-2^1205*3-1" -h"helper_09"
PFGW Version 3.4.4.64BIT.20101104.x86_Dev [GWNUM 26.4]


CPU Information (From Woltman v25 library code)
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
CPU speed: 3500.00 MHz, 4 cores
CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2, SSE4.1, SSE4.2
L1 cache size: unknown
L2 cache size: 256 KB, L3 cache size: 8 MB
L1 cache line size: unknown
L2 cache line size: 64 bytes
TLBS: 64

Primality testing 2^4423-2^1205*3-1 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Reading factors from helper file helper_09
Running N-1 test using base 3
Generic modular reduction using generic reduction FFT length 448 on A 4425-bit number
Running N+1 test using discriminant 13, base 2+sqrt(13)
Generic modular reduction using generic reduction FFT length 448 on A 4425-bit number
Calling N+1 BLS with factored part 27.68% and helper 0.23% (83.29% proof)
2^4423-2^1205*3-1 is Fermat and Lucas PRP! (0.1944s+0.0257s) [/code]

_09.in:
[code]
n=2^4423-2^1205*3-1
F=1
G=2^1205*11*67033
[/code]

[code]
gp < CHG.GP
Reading GPRC: /etc/gprc ...Done.

GP/PARI CALCULATOR Version 2.7.2 (released)
amd64 running linux (x86-64/GMP-6.0.0 kernel) 64-bit version
compiled: Sep 19 2014, gcc version 4.9.1 (Debian 4.9.1-14)
threading engine: pthread
(readline v6.3 disabled, extended help enabled)

Copyright (C) 2000-2014 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes
WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 500000
*** Warning: new stack size = 134217728 (128.000 Mbytes).
realprecision = 15008 significant digits (15000 digits displayed)

Welcome to the CHG primality prover!
------------------------------------

Input file is: TestSuite/_09.in
Certificate file is: TestSuite_09.out
Found values of n, F and G.
Number to be tested has 1332 digits.
Modulus has 369 digits.
Modulus is 27.684648779108303772% of n.

NOTICE: This program assumes that n has passed
a BLS PRP-test with n, F, and G as given. If
not, then any results will be invalid!

Square test passed for G >> F. Using modified right endpoint.

Search for factors congruent to 1.
Running CHG with h = 10, u = 4. Right endpoint has 226 digits.
Done! Time elapsed: 17748ms.
Running CHG with h = 10, u = 4. Right endpoint has 213 digits.
Done! Time elapsed: 15741ms.
Running CHG with h = 9, u = 3. Right endpoint has 190 digits.
Done! Time elapsed: 12148ms.
Running CHG with h = 7, u = 2. Right endpoint has 157 digits.
Done! Time elapsed: 8517ms.
Running CHG with h = 7, u = 2. Right endpoint has 116 digits.
Done! Time elapsed: 4680ms.
A certificate has been saved to the file: TestSuite_09.out

Running David Broadhurst's verifier on the saved certificate...

Testing a PRP called "TestSuite/_09.in".

Pol[1, 1] with [h, u]=[7, 2] has ratio=4.670568865392464778 E-251 at X, ratio=8.148375158710707375 E-240 at Y, witness=5.
Pol[2, 1] with [h, u]=[7, 2] has ratio=0.5573927723486209173 at X, ratio=2.3698841451812667437 E-82 at Y, witness=5.
Pol[3, 1] with [h, u]=[8, 3] has ratio=1.0000000000000000000 at X, ratio=9.829104895076774857 E-100 at Y, witness=7.
Pol[4, 1] with [h, u]=[9, 4] has ratio=1.0425340086454014303 E-99 at X, ratio=3.140269697688937236 E-94 at Y, witness=11.
Pol[5, 1] with [h, u]=[10, 4] has ratio=9.359357312492652555 E-26 at X, ratio=3.489446171608562181 E-53 at Y, witness=7.

Validated in 1 sec.


Congratulations! n is prime!
Goodbye!
[/code]

This is probably less CPU intensive than Primo. :smile:

axn 2015-10-13 11:08

[QUOTE=paulunderwood;412557]This is probably less CPU intensive than Primo. :smile:[/QUOTE]

Considering that this is not accepted by factordb, it is entirely wasted CPU.

pakaran 2015-10-16 18:22

Taking everything through 2384 digits.

schickel 2015-10-17 17:21

Incoming [URL="http://factordb.com/index.php?id=1100000000455154169"]certificate[/URL].

Also, Matthew posted a much bigger [URL="http://factordb.com/index.php?id=1000000000012354935"]one[/URL].

pakaran 2015-10-19 17:18

Nice!

I'm working on clearing up the 62 PRPs not significantly over 1k dd. I'll post again if I decide to do anything higher, and would ask others to do the same.

pakaran 2015-10-21 02:24

Taking the bottom 128 (through 1200 dd).

pakaran 2015-10-21 04:18

And I'm done for now.

pakaran 2015-10-22 19:01

Taking 135 smaller numbers, through 1191 dd.

pakaran 2015-10-25 00:05

Taking the 450 (!) smallest numbers.

chris2be8 2015-10-25 17:14

I've spotted a couple of shortcuts: [code]
1100000000804637633 ((61^1019-59^1019)/2+1)/199822
1100000000804637626 (61^1019-59^1019)/2

1100000000804638204 ((13^2099-11^2099)/2-1)/302256
1100000000804638199 (13^2099-11^2099)/2
[/code] After proving the smaller one of each pair you can quickly prove the larger by N+1 or N-1. Which should save you the time needed to create a certificate.

Chris

pakaran 2015-10-25 21:55

Thanks. I may have already done those. In any case, I'm done for now. There's quite a few numbers between 1800 and 3000 digits, but I have BOINC work to do, and will leave them to someone with better hardware.

pakaran 2015-10-29 02:54

Doing everything through 2034 digits; should be done by tomorrow evening.

pakaran 2015-10-30 18:48

Taking through 2412 dd. I don't recall where the optimal point is to go to the next higher sieve size, so to be conservative, if I end up working bigger than that, I'll do a separate run set to 3k dd.

pakaran 2015-11-03 00:19

I'm done for the time being.

pakaran 2015-11-11 19:57

I'm planning to bite the bullet and do everything below 3k digits.

pakaran 2015-11-15 03:24

And I'm done. Numbers were appearing faster than I could prove them.

pakaran 2015-11-21 22:32

I'm going to make another effort at everything below 2100 digits. Thanks to whomever took care of the larger numbers.

pakaran 2015-11-28 02:51

I am, once again, done. I am not sure where the sheer quantity of numbers right around 1k dd are coming from.

schickel 2015-11-29 05:38

Between the time I finished sieving my latest NFS job and decided which machine to run the LA on after the matrix building, I managed to finish about 1000+ certificates. I'm going to do the LA on my hex-core, so I'm about done with the certificates for a while. [QUOTE=pakaran;417442]I am, once again, done. I am not sure where the sheer quantity of numbers right around 1k dd are coming from.[/QUOTE]I know "where" (why) but I don't know "who". The greater majority of the certs I just did were all of the form [tex](10^{320}+m)/n[/tex] or [tex](10^{1000}+m)/n[/tex]. So it looks like someone is just generating 310-320 digit or 980-1000 digit primes for some reason. As of right now there are just over 4,000 PRPs under 3000 digits waiting.

pakaran 2015-12-30 19:38

Taking (10^3210*58+41)/99 with database ID 1100000000032098915

pakaran 2016-01-02 00:22

Done, and taking 10^4242-8000000001

schickel 2016-02-14 20:56

I started to clear out the PRPs again and right now it's a losing battle. There are 60,000+ less than 3000 digits, with hundreds ranging from 18-299. Someone is obviously spamming the DB right now. :down:

Stargate38 2016-02-15 17:19

Is it cmd again? Although cmd's banned from MersenneForum, he/she might still have access to the DB. Maybe cmd's taking revenge on us for being banned. It's just a theory, though, no proof.

EDIT: The DB is offline right now, saying "Creating backup, offline for ~1 hour", so it should be back up soon.

wblipp 2016-02-15 21:02

[QUOTE=schickel;426374]I started to clear out the PRPs again and right now it's a losing battle. There are 60,000+ less than 3000 digits, with hundreds ranging from 18-299. Someone is obviously spamming the DB right now. :down:[/QUOTE]

factordb will automatically prove everything under 300 digits. Sustained factors in that range usually means the worker dedicated to that task is not functioning for some reason. Sometimes it comes back on it's on, sometimes an email to Markus helps.

schickel 2016-02-16 00:35

[QUOTE=wblipp;426499]factordb will automatically prove everything under 300 digits. Sustained factors in that range usually means the worker dedicated to that task is not functioning for some reason. Sometimes it comes back on it's on, sometimes an email to Markus helps.[/QUOTE]All the local workers were on line and running, I was just pointing out that someone was spamming the DB faster than the sub-300s could be cleared. It looks like they're clear now, but the 300-3000 backlog is almost at 60,000. As soon as I finish the range I'm running in the Amicable number search, I'll run some more certificates to help clear it up.

GP2 2016-10-03 20:47

Request: can someone run [URL="http://factordb.com/index.php?id=1100000000869501428"]the recently-discovered 1472-digit PRP cofactor of M5233[/URL] through Primo and submit the certificate to factordb?

I had trouble with Primo as it seems to be GUI only, and the only Linux machines I have access to are virtual machines with a command line interface. Also, the binary-only executable seems to want some additional libraries to be installed...

VBCurtis 2016-10-04 01:51

I've not done a non-trivial Primo proof, but I did set up and test the software last fall, so I should be able to fire up this certificate tomorrow.

schickel 2016-10-04 04:34

[QUOTE=GP2;444177]Request: can someone run [URL="http://factordb.com/index.php?id=1100000000869501428"]the recently-discovered 1472-digit PRP cofactor of M5233[/URL] through Primo and submit the certificate to factordb?

I had trouble with Primo as it seems to be GUI only, and the only Linux machines I have access to are virtual machines with a command line interface. Also, the binary-only executable seems to want some additional libraries to be installed...[/QUOTE]

[QUOTE=VBCurtis;444189]I've not done a non-trivial Primo proof, but I did set up and test the software last fall, so I should be able to fire up this certificate tomorrow.[/QUOTE]Let me know if you don't and I can run it shortly.

GP2 2016-10-04 15:50

[QUOTE=VBCurtis;444189]I've not done a non-trivial Primo proof, but I did set up and test the software last fall, so I should be able to fire up this certificate tomorrow.[/QUOTE]

It looks like a certificate was already uploaded by Batalov earlier this morning.

Jayder 2016-10-29 19:16

Is anybody having issues uploading certificates? It has been a long time since I've done this, so maybe I'm doing something wrong. I took all of the .out files (1000 of them) and put them in a .zip. It tells me that 0 certificates are found. If I try uploading a single certificate, it doesn't take it and only returns with a period as a message: "."

RichD 2016-10-29 21:22

If you are using the latest Primo v.4.2.1, factordb doesn’t recognize them. The verifier supposedly would check them but it appears the parser, or gatekeeper, won’t allow them to be passed to the verifier. I don’t know of a site that archives the older Primo v.4.1.1.

I have dozens of certs in the 1000-5000 digit range but I don’t know of a way to convert them to the older format for verification. Arg!

Jayder 2016-10-30 07:48

That would be the case. Thank you for telling me. The latest I have is 4.0.1. Anybody have anything later?

Jayder 2016-11-01 07:37

I recently built a dual-socket machine and I was considering trying to make a dent in the certificates under 3000dd, but the lack of support is a real downer.

schickel 2016-11-14 15:07

[QUOTE=RichD;445979]If you are using the latest Primo v.4.2.1, factordb doesn’t recognize them. The verifier supposedly would check them but it appears the parser, or gatekeeper, won’t allow them to be passed to the verifier. I don’t know of a site that archives the older Primo v.4.1.1.[/QUOTE][QUOTE=Jayder;445991]That would be the case. Thank you for telling me. The latest I have is 4.0.1. Anybody have anything later?[/QUOTE]Was there a change between 4.0.1 and 4.1.1 that the verifier didn't like? I had been using 4.0.0 a13 back in 2012 for certs.

ETA: also, what are the chances that the PRPs I've been clearing might have beaten yours in? I've been working on the backlog for a couple of weeks ~1000-1500 at a time (from the bottom; ~10,000 cleared so far).

Jayder 2016-11-15 02:24

[QUOTE=schickel;447190]Was there a change between 4.0.1 and 4.1.1 that the verifier didn't like? I had been using 4.0.0 a13 back in 2012 for certs.

ETA: also, what are the chances that the PRPs I've been clearing might have beaten yours in? I've been working on the backlog for a couple of weeks ~1000-1500 at a time (from the bottom; ~10,000 cleared so far).[/QUOTE]
Take a look at the [URL="http://www.ellipsa.eu/public/primo/changes.html"]changelog[/URL]. I was using 4.2.1. 4.2.0 introduced a new certificate format. 4.1.1 is the most recent version that still works, but I only had 4.0.1 available to me.

This is undoubtedly the issue.

I was thinking that I would email Markus and see if he can take another look at the parser.

schickel 2016-11-15 03:41

[QUOTE=Jayder;447219]Take a look at the [URL="http://www.ellipsa.eu/public/primo/changes.html"]changelog[/URL]. I was using 4.2.1. 4.2.0 introduced a new certificate format. 4.1.1 is the most recent version that still works, but I only had 4.0.1 available to me.

This is undoubtedly the issue.

I was thinking that I would email Markus and see if he can take another look at the parser.[/QUOTE]so then I guess my question is why not use 4.0.1, or do you mean you updated to 4.2.1 and don't have 4.0.1?

Jayder 2016-11-15 07:03

The most recent version I had was 4.0.1, but a kind soul gave me a download for 4.1.1, so this conversation is a bit moot.

I would have used it, though, if that was all that was available to me. But wouldn't you agree that it is nice to have the most recent version of a program? (Maybe we won't include Windows here.) I don't know how much the new discriminants help, but there were quite a few added after 4.0.1, not to mention a few minor features and bug fixes. Is there a reason why you're so curious?

Jayder 2016-11-24 08:18

Good news, folks! Markus has informed me that he has fixed the bug which caused format 4 certificates to be rejected. I have uploaded the format 4 certificates that I have and can confirm that it works splendidly. Thank you, Markus!

In a [I]very[/I] small test, I have found that version 4.2.1 is at least 10% faster than 4.1.1. Well worth upgrading.

I am going to do some certificate testing above 2000 digits. Where is everybody working right now?

henryzz 2016-11-24 23:11

[QUOTE=Jayder;447676]Good news, folks! Markus has informed me that he has fixed the bug which caused format 4 certificates to be rejected. I have uploaded the format 4 certificates that I have and can confirm that it works splendidly. Thank you, Markus!

In a [I]very[/I] small test, I have found that version 4.2.1 is at least 10% faster than 4.1.1. Well worth upgrading.

I am going to do some certificate testing above 2000 digits. Where is everybody working right now?[/QUOTE]
Gonna try and make a dent in the 985 digit prps.

Jayder 2016-11-27 08:18

Primo
 
An important note about Primo: Disregard my previous comment(s) about 4.2.1. I have performed a test on 195 2000dd PRPs, comparing Primo 4.2.1 and 4.1.1 with 48 concurrent tasks.

When comparing [B][U]wall-clock time[/U][/B], I have found that 4.2.1 took 5% longer than 4.1.1 to complete the batch. Phase 1 is faster with 4.2.1, taking only 92% of the time that 4.1.1 required. The problem lies with Phase 2, which took 43% longer than 4.1.1.

When comparing [B][U]process time[/U][/B], I have found that 4.2.1 completed the batch in 90% of the time needed by 4.1.1. Phase 1 is faster with 4.2.1, taking only 87% of the time that 4.1.1 required. Phase 2 took 8% longer than 4.1.1.


For 4.2.1, the big difference in Phase 2 time when comparing wall-clock time and process time is explained by there being polynomials that are harder to factor (or so I believe). This leaves a few threads running for a long time (sometimes for half the duration of Phase 2) on a few harder polynomials, while the rest of the threads sit idle.


Somebody please correct me if I'm wrong, but I believe the takeaway is this: If you run multiple instances of Primo and are able to max out your processor(s), use 4.2.1 over 4.1.1. If you are running only one instance and wall-clock time matters more, use 4.1.1. If you are a crazy person, use 4.2.1 for Phase 1 and 4.1.1 for Phase 2.

Data for those interested (all three of you) can be found here:
[URL="https://docs.google.com/spreadsheets/d/1at2XIdtWqKMY7bm8mTFBwJmxmEONL18vwCV2AMV1GgU/edit?usp=sharing"]:barbie:[/URL]

EDIT: I forgot to mention that 4.2.1 produces smaller certificates. The 195 certificates produced by 4.2.1 take up 60.1MiB of space, while 4.1.1's 195 certificates take up 90.7MiB.

Jayder 2016-11-27 08:24

I am currently working on 990-993. I was a bit dumb and didn't check the distribution of PRPs. Seeing how clumped it is from 985 to 1005, I've moved my machine to that range. I should have 990-993 done in 2-3 days. Once my current range is complete, I'll keep working upwards.

If I am treading in anyone's area, please let me know and I will adjust accordingly. A PM will get my attention the quickest.

schickel 2016-11-27 08:57

[QUOTE=Jayder;447893] If you are running only one instance and wall-clock time matters more, use 4.1.1. If you are a crazy person, [B]use 4.2.1 for Phase 1 and 4.1.1 for Phase 2.[/B]
[/QUOTE]Unfortunately, according to Marcel that won't work:[quote]Due to numerous changes, it is impossible to resume with a 4.2.x version a certification started with a version prior to 4.2.0.[/quote]I would assume that if they're not forward compatible they're also not back compatible.

Thanks for the timing info, it'll be interesting to see how high I can push certs with the new version (biggest system I've got is a hex-core AMD).[QUOTE=Jayder;447894]I am currently working on 990-993. I was a bit dumb and didn't check the distribution of PRPs. Seeing how clumped it is from 985 to 1005, I've moved my machine to that range. I should have 990-993 done in 2-3 days. Once my current range is complete, I'll keep working upwards.

If I am treading in anyone's area, please let me know and I will adjust accordingly. A PM will get my attention the quickest.[/QUOTE]I think that you, I, and henryzz are the only ones doing certs right now. Working up from where you started should be fine. I like to keep the small stuff cleared out if I can, so I usually run the new cruft before I grab a chunk of work.

schickel 2016-11-29 14:57

2 Attachment(s)
Nice!

henryzz 2016-12-08 11:18

Just thought I would point out that I was only working on 985. 986+ are available.

Jayder 2016-12-08 17:49

I was wondering about that. When I'm done my batch going from 1000 - ~1800 I'll do those ones.

schickel 2016-12-10 20:42

1 Attachment(s)
For one glorious instant (someone has a job running that crams more PRPs in as they get cleared):

chris2be8 2016-12-11 17:05

That is probably my script adding algebraic factors to composites in factordb. It's partly (and sometimes fully) factoring a few thousand numbers per day. And some of them will be left as one big PRP after algebraic factors are removed.

Chris

schickel 2016-12-11 22:44

[QUOTE=chris2be8;448951]That is probably my script adding algebraic factors to composites in factordb. It's partly (and sometimes fully) factoring a few thousand numbers per day. And some of them will be left as one big PRP after algebraic factors are removed.

Chris[/QUOTE]That makes me feel better. I didn't like the thought of someone just cramming PRPs in for the hell of it. Tackling some of the backlog of unfactored composites would at least be some progress.

Jayder 2016-12-13 00:21

[QUOTE=schickel;448910]For one glorious instant (someone has a job running that crams more PRPs in as they get cleared):[/QUOTE]
Isn't it nice? :)

Any ranges that I should stay out of? Can I go as low as 300?

schickel 2016-12-13 05:45

[QUOTE=Jayder;449039]Isn't it nice? :)[/quote]Very nice! The count for PRPs <3000 digits stood at 100,000+ before this last burst of proving. We're down to <30,000 currently.[quote]Any ranges that I should stay out of? Can I go as low as 300?[/QUOTE]I don't think there are very many working on the PRPs right now: me, you, henryzz, pakaran was last active a year ago.

I like to grab everything under 1000 digits every so often and work them with one of my slower systems (it's still running the Win version.) Don't let that stop you, though, there will still be more if you finish everything again. :grin:

schickel 2016-12-22 15:46

Fantastic: a couple of more dumps from Jayder and we'll have the PRPs <3000 digits conquered again. After the current batch finishes, we'll be at ~12,500 and I've got a batch of 600 that will be done this afternoon, so almost there!

pakaran 2017-01-02 02:50

I went inactive because I have my new machine running straight Windows 10.

Has anyone got Primo running under VM? Sorry if this is an FAQ.

schickel 2017-01-02 07:35

[QUOTE=pakaran;450303]I went inactive because I have my new machine running straight Windows 10.

Has anyone got Primo running under VM? Sorry if this is an FAQ.[/QUOTE]I run Primo in VirtualBox under Windows 7. It was actually easy to set up. Just download a Linux distro, create a VHD to install on, mount the .iso image in VirtualBox, and boot the virtual machine to install.

Best scenario is running a 64-bit host since Primo is 64-bit. I think you can run a 64-bit guest on a 32-bit host, but I'm not sure what kind of speed penaly you might face. I'm running Ubuntu (not the most current version, since the VM doesn't emulate the video hardware to run it optimally.) It also helps to have a current CPU that supports the virtualization stuff to help the execution speed..

danaj 2017-01-02 20:05

I have a new Windows 10 laptop I got for development while traveling, and one of the first things I did was add VirtualBox with Ubuntu. It seems to work just fine -- it's an Ubuntu machine running at the same time as Win10.

It's an i7-6700HQ and I needed to go into the BIOS and turn on VT-x, which is apparently commonly off by default on laptops. That enables running 64-bit guest OS's, which is pretty critical. I gave it 4 CPUs and 8GB RAM (the processor is a 4/8 just like many of the Intel i7 desktops, albeit at a lower clock speed, and the machine has 16GB of RAM total).

I just downloaded Primo 4.2.1 from the website, install p7zip, and ran it. No issues.

Time for "Titanic1" using 4 CPUs and all default settings: 55.6s. i7-6700HZ 3.1GHz (that's what CPU-Z indicated while it ran primo -- it's highly dynamic based on load).

Time on my desktop: 43.3s. i7-6700K 4.2GHz (and faster memory).

The ratio of times is not dis-similar from the ratio of clock speeds. The tradeoff is that the slower machine is highly portable and did all that on battery power, while the desktop is not.

On the desktop, using 8 threads cuts the time down to 34.6s. I would need to restart the VM to test that on the laptop.

danaj 2017-01-03 18:14

What I didn't make clear in the last message, that was kind of the point, was that the desktop is running Fedora natively. So there doesn't seem to be an appreciable time penalty for running inside VirtualBox on a recent Intel machine.

pakaran 2017-01-04 16:47

Thank you both. I think that'll be my next project, though I'm not ready to make reservations now (crazy work schedule for awhile).

Jayder 2017-02-01 10:00

I have set my machine back to certificate work. I've taken a chunk from 300dd and up. If you are working in that area, let me know and I'll hold off on uploading.

Jayder 2017-02-12 06:17

Good news and bad news:

The good news: as of the time of this posting, there are only 3,886 PRPs under 3000dd in the database.

The bad news: Certifying these 3,886 numbers will give the equivalent score of a single 19,320dd certificate. My estimate is that it will take at least 3 months to complete them all.

If anybody is working anywhere, please let me know. I could use some help cleaning up the sub-2000dd range as new ones are introduced into the database.

schickel 2017-02-12 19:40

[QUOTE=Jayder;452817]Good news and bad news:

The good news: as of the time of this posting, there are only 3,886 PRPs under 3000dd in the database.

The bad news: Certifying these 3,886 numbers will give the equivalent score of a single 19,320dd certificate. My estimate is that it will take at least 3 months to complete them all.

If anybody is working anywhere, please let me know. I could use some help cleaning up the sub-2000dd range as new ones are introduced into the database.[/QUOTE]Wow, that is a lot of proving you've put it.

I had actually given up on trying to clear the sub-3000 area because the PRPs were being added faster than I could clear them. I might have to put an oar back in the water on this. I'll see what I've got lined up for my machine.

EdH 2017-02-14 03:03

I can come play for a while. What range would you like me to work? Should I just grab what shows up as default or is there a better area?

For now, I'll grab 100 at 1300 and see what happens...

EdH 2017-02-14 15:04

Unless someone tells me to, "stop it!" I'll do another 100 starting at 1300...

EdH 2017-02-14 17:29

[QUOTE=EdH;452937]Unless someone tells me to, "stop it!" I'll do another 100 starting at 1300...[/QUOTE]
Well, I guess I messed up a bit. I don't see any at 13xx, so I probably did some above 2xxx. I see, if I'm looking in the right place now, that there are a few hundred at 9xx. I will not do any more until I find out where others are and what area they would like me to cover...

Jayder 2017-02-15 07:46

Oops, I made a slight miscalculation in my estimate for how long it would take to finish what is currently under 3000dd. It's more like 1-1.5 months. I hope. :smile:

I've just submitted the latest batch of certificates so with you folks joining in I'll work solely from 2500-3000dd (roughly 1500 numbers). 64% of the effort lies above 2500dd, so that is plenty for my machine to chew on for 2-3 weeks. I'll take it in batches of 500.


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

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