Database Flooding

[Antonio]

For those people who tried my Perl script, here is the latest update.

Major change is a bug-fix in the throttling code, it now correctly counts the Factordb page requests (I hope) and added some extra checks, as far as I can determine, it will no longer exceeds the 1500 pages/hour limit when working on lots of easily factored composites.

Minor changes to clean up the script and add extra comments.

[Jayder]

Thanks Antonio!

[Stargate38]

Who's been adding thousands of PRPs that are less than 10³⁰⁰? Here's an example:

http://factordb.com/index.php?id=1100000000739412775

It doesn't divide any other numbers in the db. They're all like that. By the time I clicked on it, it was already proven.

Update: They're all proven now.

[Puzzle-Peter]

Originally Posted by Stargate38

Who's been adding thousands of PRPs that are less than 10³⁰⁰? Here's an example:

http://factordb.com/index.php?id=1100000000739412775

It doesn't divide any other numbers in the db. They're all like that. By the time I clicked on it, it was already proven.

I am not sure how factordb works. Does it check every new entry if it is a factor for one or several of the older entries? I.e. can we be sure they do not divide any of the other entries?

[wblipp]

Originally Posted by Stargate38

Who's been adding thousands of PRPs that are less than 10³⁰⁰? Here's an example:

http://factordb.com/index.php?id=1100000000739412775

1. Anything under 300 digits is proven by factordb's own resources. Seeing this means that you happened to be looking after it was submitted but before factordb got around to it. These are quick to prove, so it is not surprising that it was proven by the time you got back to it.

2. I've been adding the fully factored numbers from OddPerfect.org. These numbers are almost all of the form (p^q-1)/(p-1), with p and q both prime. I recently added a new batch of pretty small numbers where the whole number is prime. It looks like you happened by in the midst of that.

3. Somebody else, not me, seems to be recently looking at p+1 and p-1 proofs for primes just above the 300 digit threshold. I deduce this from the observation that the bottom end of the PRP list is often full of primes that finish such an a proof.

[chris2be8]

@Puzzle-Peter

It doesn't check if new entries divide an existing entry, there are far too many entries for that to be practical. Right now there are 41,119,907 composite numbers without known factors in factordb, checking if a new prime divides any of them would take hours if not days.

Chris

[chris2be8]

Originally Posted by wblipp

3. Somebody else, not me, seems to be recently looking at p+1 and p-1 proofs for primes just above the 300 digit threshold. I deduce this from the observation that the bottom end of the PRP list is often full of primes that finish such an a proof.

I've been going through the PRPs in factordb doing that. Sometimes I just need to click the proof button, more often I add algebraic factors for P+1 or P-1 and then prove it if there are enough prime factors. But quite often I don't get enough to prove the number prime.

But there are a lot of PRPs in the list that can't be proved that way. So I spend a lot of time searching for needles in a haystack.

Chris

[Puzzle-Peter]

Originally Posted by chris2be8

@Puzzle-Peter

It doesn't check if new entries divide an existing entry, there are far too many entries for that to be practical. Right now there are 41,119,907 composite numbers without known factors in factordb, checking if a new prime divides any of them would take hours if not days.

Chris

Thanks for clearing for that up.

[kar_bon]

Someone's spammed FDB with ~1k numbers of 85 Digits like 2812402497...98<85><.
These guys should be dammend to factor them by hand!

[Antonio]

Originally Posted by kar_bon

Someone's spammed FDB with ~1k numbers of 85 Digits like 2812402497...98<85><.
These guys should be dammend to factor them by hand!

Not just there, but spamming from 70 digits up, I've cleared about 3000 in the last 10 hours and working through 83 digits at the moment.
It's good exercise for my latest Perl script update, which seems to be withstanding the onslaught well.

I have attached it here for anyone interested. Changes since the previous version: -

1. Cleared a bug which could cause an endless wait for composite to be in range.
2. Corrected 'page request' count, and removed unnecessary database calls.

[ChristianB]

Originally Posted by Antonio

Not just there, but spamming from 70 digits up, I've cleared about 3000 in the last 10 hours and working through 83 digits at the moment.
It's good exercise for my latest Perl script update, which seems to be withstanding the onslaught well.

I have attached it here for anyone interested. Changes since the previous version: -

1. Cleared a bug which could cause an endless wait for composite to be in range.
2. Corrected 'page request' count, and removed unnecessary database calls.

Hi Antonio,

can you make this available on github.com? I had to tweak your script to get it working on debian and would also like to include a cookie to the web requests to have higher limits on queries per hour. Having this in source control should make it easier to implement those changes and keep it working on windows and linux.