On the Infinity of Twin Prime and other K-tuples

[jzakiya]

I updated the paper and code yesterday (June 28, 2022 -- Tau Day).

I found 2 places in the code that allowed arithmetic overflow, that I fixed in all versions.
I also fixed some typos, and clarified|simplified some language, and explained the code changes.

The updated paper is available at the previously provided links, and I've attached a copy here.

[Rustum]

Originally Posted by Till

I have been provided with a Java implementation of this sieve a couple of months ago. You can find it here:
https://github.com/TilmanNeumann/jav...act/SSOZJ.java

My impression was that it is very fast.

Yes, it is fast, and most of the time it works correctly. However, the twin primes it gives are sometimes incorrect, suggesting that a bug is present in the Java source code. Here is an example.

T:\PRIMES>java TNeumann.SSOZJ
Please enter an range of integer (comma or space separated):
16850900 16851030
 Max threads = 12
Using Prime Generator parameters for given Pn 5
segment size = 5 resgroups; seg array is [1 x 1] 64-bits
twinprime candidates = 15 ; resgroups = 5
each 3 threads has nextp[2 x 561] array
setup time = 0.026 secs
perform twinprimes ssoz sieve with s=6
3 of 3 threads done
sieve time = 0.008 secs
last segment = 5 resgroups; segment slices = 1
total twins = 1; last twin = 16850988+/-1
total time = 0.034 secs

Factors of 16850989: 4099 4111

[Till]

Originally Posted by Rustum

Yes, it is fast, and most of the time it works correctly. However, the twin primes it gives are sometimes incorrect, suggesting that a bug is present in the Java source code. Here is an example.

T:\PRIMES>java TNeumann.SSOZJ
Please enter an range of integer (comma or space separated):
16850900 16851030
 Max threads = 12
Using Prime Generator parameters for given Pn 5
segment size = 5 resgroups; seg array is [1 x 1] 64-bits
twinprime candidates = 15 ; resgroups = 5
each 3 threads has nextp[2 x 561] array
setup time = 0.026 secs
perform twinprimes ssoz sieve with s=6
3 of 3 threads done
sieve time = 0.008 secs
last segment = 5 resgroups; segment slices = 1
total twins = 1; last twin = 16850988+/-1
total time = 0.034 secs

Factors of 16850989: 4099 4111

Well, admittedly I didnt't test the program extensively. For a start I will comment the error in the javadoc. Maybe Pascal Pechard is willing to investigate it.

[Batalov]

Originally Posted by Till

Well, admittedly I didnt't test the program extensively. For a start I will comment the error in the javadoc. Maybe Pascal Pechard is willing to investigate it.

"У семи нянек дитя без глаза", the Russian proverb says. "There are too many cooks in the kitchen."

If seven cooks only care about their part of the recipe and then put it all together in a soup, trust me - you won't want to eat it.

[jzakiya]

Here are the correct results using Rust (other versions give same result).
I haven't looked at that code in awhile, but I informed its author.

echo 16850900 16851030 | ./twinprimes_ssoz-rust 
threads = 16 
using Prime Generator parameters for P5 
segment size = 5 resgroups; seg array is [1 x 1] 64-bits 
twinprime candidates = 15; resgroups = 5 
each of 3 threads has nextp[2 x 108] array 
setup time = 0.000798284 secs 
perform twinprimes ssoz sieve 
3 of 3 twinpairs done 
sieve time = 0.00003492 secs 
total time = 0.000838024 secs 
last segment = 5 resgroups; segment slices = 1 
total twins = 0; last twin = 0+/-1

[Pascal66]

@rustulm, I'll give the correct version to @till soon.

As @jzakiya say, there's some good improvment on it, so the improved version will be online soon too.

Sorry to haven't updated the code for some years :)

[Pascal66]

A corrected version (2020->2022) is available https://gist.github.com/Pascal66/d92...fc9a787636e17c
This was pushed on @Till java math library

[Till]

Originally Posted by Pascal66

A corrected version (2020->2022) is available https://gist.github.com/Pascal66/d92...fc9a787636e17c
This was pushed on @Till java math library

Thanks Pascal, your PR is merged now and I verified that it fixes the error found by rustum.

[Till]

Originally Posted by Batalov

"У семи нянек дитя без глаза", the Russian proverb says. "There are too many cooks in the kitchen."

If seven cooks only care about their part of the recipe and then put it all together in a soup, trust me - you won't want to eat it.

Good saying, but not really appropriate here. This twin prime sieve only has two cooks and a waiter (me); and all the rest of the library has been (implemented or ported or (extensively reviewed and worked over)) and tested by myself.

[Rustum]

Thanks to Pascal66 and Till for the prompt bug fix and file updates.

[Rustum]

Originally Posted by jzakiya

I wrote a paper explaining a general theory of using what I call Prime Generators, and applied the theory to establish that Polignac's Conjecture is true, there are infinitely many pairs of primes that differ by any gap n.

This is an application of Prime Generator Theory (PGT) I began developing in 2008, and applied to creating the fastest/most efficient prime sieves, as independently verified in the link below, and a Rubygem.

https://github.com/hathix/prime-algorithms

...

It turns out that the Python codes of "hathix" have bugs (Issue 1 at the Github site). They report composite numbers as primes and leave out known primes (such as even a lowly 7) from the list of primes.

Until these bugs are fixed and the output lists of primes have been verified, any conclusions (regarding the correctness of the so called Prime Generators or the speed of the algorithm) are premature.