Other Factordb Problems - Page 3

Stargate38 · 2014-06-13, 19:34

I'm having a problem with the Certificates page. It won't keep the "Show Unprocessed Only" Checked:

http://www.factordb.com/certoverview...p=0&pending=on

Stargate38 · 2014-06-14, 17:55

I tried adding M67,108,864 (20,201,782 digits), but it said "Error: Limit of about 10,000,000 digits exceeded". If that's true, then why is it possible to add M57885161 (17,425,170 digits) and all other known primes >10^10[sup]7[/sup]?

Here's links for proof:
http://www.factordb.com/index.php?query=M57885161 (Doesn't give Max. digits error), alt link: http://www.factordb.com/index.php?id...00000583604171
http://www.factordb.com/index.php?query=M67108864 (Gives Max. digits error)
http://www.factordb.com/index.php?query=M66438561 (Largest Mersenne number <10^20000000, still gives error)

wblipp · 2014-06-14, 21:05

Perhaps Syd recently added a certificate size limitation. I had a recent email from Syd explaining that the recent stall in processing primality certificates was because of some large certificates that took over a week to process.

danaj · 2014-06-14, 23:52

Over a week, ouch. For a 18689 digit prime, currently the 12th largest on the primes page, I got a time of 63 hours with my single threaded program on 4770K that had 4 other processes running. Primo for the same cert took 6 hours on an idle 3930K given 12 threads. Clearly a 4770K is faster than the i7-2600, but that's pretty long.

I'd recommend upgrading to GMP 6.0.0a, as that had some pretty major speed updates (~1.2x faster) that impact these operations . Tthe above time was not with it.

Another possibility is to split up the verification into steps. E.g. a "--step <n>" option that says just do that step, and a "--structure" option to verify the structure and return the number of steps. It would allow finer granularity and not lock up one process on a very long running task.

Or maybe Syd has already found a different solution, as the status page looks like things are moving along.

chris2be8 · 2014-06-15, 16:00

Perhaps the limit of "about 10,000,000 digits" is actually between 17,425,170 and 20,201,782 digits. Or Syd might have added M48 as a special case.

Chris

Puzzle-Peter · 2014-06-15, 17:07

I don't think a single huge certificate is a problem. I and others have uploaded the occasional one and though it takes a long time, there was usually one of these and two or three other workers happily processing the small ones.

Last week however, user msc_nbg uploaded hundreds of certificates for numbers with 10,000+ digits. They all differ in a tiny number of digits, so it MIGHT be the steps that the ECPP proof takes as it is created by a row of primes decreasing in size. THIS IS JUST A GUESS! Anyway this would easily clog up the certificate processing and it would be a rather easy thing to generate these certificates after having done a big PRIMO run.

Just my 2 cents and I might be completely wrong.

TimSorbet · 2014-06-15, 18:20

Quote:

Originally Posted by Puzzle-Peter

Last week however, user msc_nbg uploaded hundreds of certificates for numbers with 10,000+ digits. They all differ in a tiny number of digits, so it MIGHT be the steps that the ECPP proof takes as it is created by a row of primes decreasing in size. THIS IS JUST A GUESS! Anyway this would easily clog up the certificate processing and it would be a rather easy thing to generate these certificates after having done a big PRIMO run.

Just my 2 cents and I might be completely wrong.

Maybe the person's thinking was, "My ECPP proof has this chain of things that are all proved prime (even though only the first was noteworthy enough to want to prove). I should tell the DB about all of them!".
Maybe the DB should (if it doesn't already) look at the certificate, and add all of the primes proved in this chain to the DB. This would also mean that it doesn't have to reprocess a certificate chain over and over. (this could be done regardless of if your guess here is right, and that's what happened here)

Puzzle-Peter · 2014-06-16, 09:46

Quote:

Originally Posted by Mini-Geek

Maybe the person's thinking was, "My ECPP proof has this chain of things that are all proved prime (even though only the first was noteworthy enough to want to prove). I should tell the DB about all of them!".
Maybe the DB should (if it doesn't already) look at the certificate, and add all of the primes proved in this chain to the DB. This would also mean that it doesn't have to reprocess a certificate chain over and over. (this could be done regardless of if your guess here is right, and that's what happened here)

After one of my first PRIMO certificates I did wonder about that myself. I was simply too lazy to take action. Plus - as others pointed out - the probability of "recycling" one of those primes is just about zero so I didn't bother.

Still they are proven primes and why not store them in FactorDB. I think extracting them from the certificates is a good idea and shouldn't be too hard to do.

wblipp · 2014-06-16, 16:13

Quote:

Originally Posted by Puzzle-Peter

the probability of "recycling" one of those primes is just about zero

I still find this argument compelling. It might be possible to convince me to support a database modification that stored the one certificate and tagged all the primes as proven by that one certificate. But I oppose the successive shortening of the certificate and resubmission after each shortening as a waste of resources - both computing and storage resources. I doubt Syd has the time to make such a database modification.

danaj · 2014-06-17, 01:21

It's come up before, and I wrote a simple Perl program to create new verifiable certs just to make sure it could be practically done. But I think it's a really bad idea. If desired, this is something the database should efficiently store (just a note that the proof for number N is step 45 of entry XXXXX), and generate the small cert from the larger one if requested.

Stargate38 · 2014-06-17, 16:00

I think I found the DB's max value. It's somewhere between M62000000 and M62000001, but I was able to get M62000001 by typing in "2*M62000000+1".

2014-06-14, 17:55	#24
Stargate38 "Daniel Jackson" May 2011 14285714285714285714 3·251 Posts	I tried adding M67,108,864 (20,201,782 digits), but it said "Error: Limit of about 10,000,000 digits exceeded". If that's true, then why is it possible to add M57885161 (17,425,170 digits) and all other known primes >10^10[sup]7[/sup]? Here's links for proof: http://www.factordb.com/index.php?query=M57885161 (Doesn't give Max. digits error), alt link: http://www.factordb.com/index.php?id...00000583604171 http://www.factordb.com/index.php?query=M67108864 (Gives Max. digits error) http://www.factordb.com/index.php?query=M66438561 (Largest Mersenne number <10^20000000, still gives error) Last fiddled with by Stargate38 on 2014-06-14 at 18:03 Reason: Add more info

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A suggestion for factordb.	enzocreti	FactorDB	24	2022-11-17 07:20
Extending Factordb	carpetpool	FactorDB	6	2017-01-23 11:04
FactorDB PRP's	smh	FactorDB	231	2015-07-28 02:30
bugged sequence in factordb	firejuggler	Aliquot Sequences	2	2010-06-15 14:03
FactorDB question	Raman	Factoring	15	2010-01-28 10:24

2014-06-13, 19:34	#23
Stargate38 "Daniel Jackson" May 2011 14285714285714285714 3·251 Posts	I'm having a problem with the Certificates page. It won't keep the "Show Unprocessed Only" Checked: http://www.factordb.com/certoverview...p=0&pending=on

2014-06-14, 21:05	#25
wblipp "William" May 2003 Near Grandkid 3×7×113 Posts	Perhaps Syd recently added a certificate size limitation. I had a recent email from Syd explaining that the recent stall in processing primality certificates was because of some large certificates that took over a week to process.

2014-06-14, 23:52	#26
danaj "Dana Jacobsen" Feb 2011 Bangkok, TH 3²×101 Posts	Over a week, ouch. For a 18689 digit prime, currently the 12th largest on the primes page, I got a time of 63 hours with my single threaded program on 4770K that had 4 other processes running. Primo for the same cert took 6 hours on an idle 3930K given 12 threads. Clearly a 4770K is faster than the i7-2600, but that's pretty long. I'd recommend upgrading to GMP 6.0.0a, as that had some pretty major speed updates (~1.2x faster) that impact these operations . Tthe above time was not with it. Another possibility is to split up the verification into steps. E.g. a "--step <n>" option that says just do that step, and a "--structure" option to verify the structure and return the number of steps. It would allow finer granularity and not lock up one process on a very long running task. Or maybe Syd has already found a different solution, as the status page looks like things are moving along.

2014-06-15, 16:00	#27
chris2be8 Sep 2009 2×1,213 Posts	Perhaps the limit of "about 10,000,000 digits" is actually between 17,425,170 and 20,201,782 digits. Or Syd might have added M48 as a special case. Chris

2014-06-15, 17:07	#28
Puzzle-Peter Jun 2009 2²×5²×7 Posts	I don't think a single huge certificate is a problem. I and others have uploaded the occasional one and though it takes a long time, there was usually one of these and two or three other workers happily processing the small ones. Last week however, user msc_nbg uploaded hundreds of certificates for numbers with 10,000+ digits. They all differ in a tiny number of digits, so it MIGHT be the steps that the ECPP proof takes as it is created by a row of primes decreasing in size. THIS IS JUST A GUESS! Anyway this would easily clog up the certificate processing and it would be a rather easy thing to generate these certificates after having done a big PRIMO run. Just my 2 cents and I might be completely wrong.

2014-06-17, 01:21	#32
danaj "Dana Jacobsen" Feb 2011 Bangkok, TH 3²×101 Posts	It's come up before, and I wrote a simple Perl program to create new verifiable certs just to make sure it could be practically done. But I think it's a really bad idea. If desired, this is something the database should efficiently store (just a note that the proof for number N is step 45 of entry XXXXX), and generate the small cert from the larger one if requested.

2014-06-17, 16:00	#33
Stargate38 "Daniel Jackson" May 2011 14285714285714285714 1361₈ Posts	I think I found the DB's max value. It's somewhere between M62000000 and M62000001, but I was able to get M62000001 by typing in "2*M62000000+1".