Database for k-b-b's:

[kar_bon]

Originally Posted by 3.14159

I don't know if it would be faster or slower to be in a group project, but even if it were faster, if I were to discover anything, the group gets the credit.

The project gets the credit as project and you as individual person, the same like the relation team and team member.

[3.14159]

I think k * n! + 1 and k * p(n)# + 1 are items 6 and 7 here.

These would be, in the long run, the easiest to find, since, when large enough, have no small prime factors to worry about.

.. k * p(5897)# + 1 should be pretty easy to find.

My odds are at 1 in 1668. Pretty easy, for a 25200-digit number.

Though there are an infinite amount of prime numbers larger than 25200 digits.

[mdettweiler]

Originally Posted by 3.14159

Karsten:

Are you doing any search work or factor work at the moment?

Also, based on the testing time, I should find something within 65 days' worth of work. Since I am restricted to only about 1/2 day, I expect something in 4-6 months.

Therefore, no more records for the rest of this year. And, dammit, I won't make it to the top 5k. The time it takes to test and the odds always prohibit me from finding anything that would be top-5000 worthy.

I don't know if it would be faster or slower to be in a group project, but even if it were faster, if I were to discover anything, the group gets the credit.

As Karsten said, primes found in a group project are credited both to you and the project; the top-5000 considers them separate rankings, so each is counted as having found a full prime. (You only have to split credit if, say, two persons collaborate on a prime, or two projects.)

The main advantage of a group project is that it usually provides presieved files. Other than that, though, if you want to get a prime for yourself through it, you still have to test the statistically predicted # of pairs. But cutting out the sieving does help quite a bit. As a case in point, the No Prime Left Behind project (yeah, I know, shameless plug) sieves huge ranges of k in multi-fixed-k sieves; this is a lot more efficient than sieving each of those k's individually, so a much higher sieve depth can be reached in the same amount of CPU time; thus, you don't have to test as many pairs to find a prime since more are eliminated in sieving.

If your goal is to find a top-5000 prime, I would recommend giving our 11th Drive a try. It's working around n=590K, which produces primes that will stay on the top-5000 for a number of weeks. They come about every 6000 tests or so, statistically. Depending on the age of your computer that could take a while, but at least you won't have to worry about your sieve file dropping under the top-5000 water line before you find a prime; we have enough other contributions going on that drive to keep it moving forward as least as quickly as the 5000th prime moves up.

[3.14159]

I sieved rather deep for two weeks.. 6.0707 * 10^13. What do you call a typical presieved file?

[mdettweiler]

Originally Posted by 3.14159

I sieved rather deep for two weeks.. 6.0707 * 10^13. What do you call a typical presieved file?

NPLB's 11th Drive is sieved to p=30T (3*10^13). But I think the optimal depth generally balances out differently for fixed-k searches than for fixed-n; you can't reach high p-values quite as fast, but you get a much broader range (in terms of k and n) covered in the same amount of time.

[3.14159]

Originally Posted by Max

NPLB's 11th Drive is sieved to p=30T (3*10^13). But I think the optimal depth generally balances out differently for fixed-k searches than for fixed-n; you can't reach high p-values quite as fast, but you get a much broader range (in terms of k and n) covered in the same amount of time.

At the cost of memory, though. It takes quite a bit of memory to save the sieved file for the multiple ranges.

[mdettweiler]

Originally Posted by 3.14159

At the cost of memory, though. It takes quite a bit of memory to save the sieved file for the multiple ranges.

With sr2sieve, the k=2000-3000, n=50K-1M sieve was actually surprisingly manageable--I don't remember exactly how much memory it used, but I do recall it fit well within 1 GB of RAM.

The sieve file on disk, of course, took up a lot more space. But that's to be expected regardless of whether the search is fixed-k or fixed-n, when you're sieving enough to keep a big distributed project busy for a few years.

[3.14159]

.. A team of a few ten thousand people should get an equal load..

[mdettweiler]

Originally Posted by 3.14159

.. A team of a few ten thousand people should get an equal load..

Um...which of the currently active conversation threads is this intended to comment on? The discussion of top-5000 credit, perhaps, or the RAM usage of large sieves?

Assuming the former: the idea is that all of the other contributors to a project get credited as part of the project's credit for each prime found. Even though this may seem a little unfair at first since only the discoverer gets direct credit, it does even out in the end since there's plenty of primes to go around for everybody.

Some projects, like the Twin Prime Search, whose aim is to find only one prime in a given search (or at most, a couple that are far and few), and who therefore don't have enough top-5000 primes to go around for everyone, try to balance this out a bit by having the discoverer, the top LLR tester, and top siever (the latter two by points calculated to be proportional to the CPU time contributed) share credit for the prime. That means each gets 1/3 prime in the "person" rankings, TPS gets 1 prime in the "project" rankings, and each of the programs involved (in this case LLR, NewPGen, and Psieve) get 1 prime in the "program" rankings. (Programs are a special case in that they don't split credit when multiple entities are listed; this is to encourage honest reporting of which programs were used.)

[kar_bon]

Originally Posted by 3.14159

.. A team of a few ten thousand people should get an equal load..

Some numbers:

NPLB's 11th drive: k=2001-2999 (495 values because 5 already checked), n=600k-1000k

The sieve-file is ~93MB in newpgen-format (one line per k n pair) and about 26.5 MB in abcd-format.
That file contains 7,136,257 candidates left at p=30T.

I've started sr2sieve with "sr2sieve -i sr_2.abcd -P 31e12" and it's using about 31.5MB memory.
It stated to find about 7500 factors in that range (p=30T-31T).

After a few seconds it founds 30000002840477 | 2581*2^727859-1, the first factor in this range.

The timing: ETA is Dez,13 with one core of a Quad, so about 11 weeks -> 3 weeks for a Quad.

No need to put thousands of people on such sieve. Better check your statements before posting false ones!

[kar_bon]

I've included a page for k*b^b-1 primes under RieselPrimeDatabase Interests.