FactorDB PRP's

[schickel]

Hmmmm....what's the maximum size on the new version? There looks to be a bunch of about ~300 up at the 58711 digit level. (Someone has been busy, it would seem; they all have the same form.)

[EdH]

Originally Posted by schickel

Hmmmm....what's the maximum size on the new version? There looks to be a bunch of about ~300 up at the 58711 digit level. (Someone has been busy, it would seem; they all have the same form.)

They have a chart on the page that shows the time for a 7000 digit number using 2^28 sieve bound (61h 28m). The program offers up to 2^30 sieve bound.

This current machine isn't on 24/7, so I'll probably just run small batches of lesser digits for a while, until the novelty wears off...

[Stargate38]

Originally Posted by schickel

Hmmmm....what's the maximum size on the new version? There looks to be a bunch of about ~300 up at the 58711 digit level. (Someone has been busy, it would seem; they all have the same form.)

They can be proven with P+1 because they're all of the form k*2ⁿ-1. Try using Prime95 or some other LLT program.

[RichD]

It looks like the wavefront is just above prp1200 (except for a few new ones) and there is also a fairly new alpha version (v4.0.0.a12) for linux posted here.

@mods: Should this be moved to FactorDB sub-topic?

[EdH]

First, (as per RichD's prior post) this thread should probably move to the factorDB sub-forum.

Second, What happened? Over 1000 each of 84 and 85 digit PRPs have shown up...

Third, will the db take care of these or should I work them? I've been working in the 1200-1300 area and the basic floor is now over 1300...

[em99010pepe]

Originally Posted by EdH

Third, will the db take care of these or should I work them? I've been working in the 1200-1300 area and the basic floor is now over 1300...

How are you doing that? Manually?

[wblipp]

Originally Posted by EdH

Second, What happened? Over 1000 each of 84 and 85 digit PRPs have shown up...

That was probably me. They get processed quickly, but if you happen to be watching during a load, it gets backed up. Processing through (p^q-1), p and q prime. I've been uploading some batches where (p^q-1)/(p-1) is prime, and some other batches where it is fully factored. It's all part of supporting the factor chains for Odd Perfect Number proofs of various kinds.

[EdH]

Originally Posted by em99010pepe

How are you doing that? Manually?

Specifically, I'm using Ellipsa > Primo for Linux with a couple 64-bit machines. I check the Smallest probable primes page in the db and normally leave the ones that are less than 1000 digits. Looking as I write this post, that means 1305 is my start point. Actually, I started a batch of 80, beginning with 1305 last night, that should be finished in a couple hours.

My steps are:

download a zipped batch of Primo input-files from db
extract files into a directory
invoke Ellipsa
build 2^22 sieve upper bound
load unzipped input-files
wait for completion
zip all the *.out files via a bash script
upload the new zip to the db

It would be nice to be able to automate the entire process, but I haven't found a way, yet. But, the fact that you can load an entire batch into Ellipsa makes it tolerable.

I have been lucky that no one else is working at the same digit level, the beginning of the "wavefront" as RichD calls it. I often just grab all of one digit size and process them before grabbing the next. If I have one of my 24/7 machines running Ellipsa, I'll load a few more, like the 80 I grabbed last night. If I start getting a lot of certificates not accepted, due to the number being processed by others, I'll jump up a random number of digits and work there. I am rather haphazard in whether I do any or not, although for the recent past I've been pretty regular.

Originally Posted by wblipp

That was probably me. They get processed quickly, but if you happen to be watching during a load, it gets backed up. Processing through (p^q-1), p and q prime. I've been uploading some batches where (p^q-1)/(p-1) is prime, and some other batches where it is fully factored. It's all part of supporting the factor chains for Odd Perfect Number proofs of various kinds.

Thanks for the reply. I see they're already gone. That was the first time I'd seen that many smaller numbers added at once. There was a slight disappointment that the overall number of PRPs, somewhere just under 67k, had suddenly jumped back up to 69k. It was a slow road watching that number decrease by a hundred here, 50 there... I had figured the 80 digit ones wouldn't take too long, but didn't know if they would be done by the db. I haven't been touching anything < 300 digits and they all seem to get done.

[schickel]

Originally Posted by EdH

Thanks for the reply. I see they're already gone. That was the first time I'd seen that many smaller numbers added at once. There was a slight disappointment that the overall number of PRPs, somewhere just under 67k, had suddenly jumped back up to 69k. It was a slow road watching that number decrease by a hundred here, 50 there... I had figured the 80 digit ones wouldn't take too long, but didn't know if they would be done by the db. I haven't been touching anything < 300 digits and they all seem to get done.

Actually, IIRC, everything under 300 digits is done by the DB. Up to that size it just runs an APRT test, so there's no cert stored.

[RichD]

It appears henryzz would like to have this thread reactivated by his post here or at least have a mod update post #1 above.

Or a sticky.

[RichD]

I will be completing the PRP certs for prp1450-1475 in the coming weeks. This is fill-in work for one of my "floating" cores.

This could easily be done in a day or two but it will be partial work in-progress. I think this is far enough ahead of the trailing edge that no one will step on me.