On the Infinity of Twin Prime and other K-tuples - Page 6

LaurV · 2020-09-09, 03:53

Quote:

Originally Posted by mart_r

one in Pari... I'm not yet familiar with coding in Perl or C

Man, if you wrote such thing in pari, then you are already "familiar" with C more than you imagine. You can give it a try using either libpari or gwnum, to avoid implementing some things from scratch (but sieving and such, there are a lot of functions and ready-made implementations already). C is extremely simple, only few instructions to learn, haha, it will be the OS you will have to struggle with (like, writing C for Windows or for Linux may be sometimes two different worlds). But you don't know until you try. Give it a try, and there are many guys here who can help you (me included). Just ask.

Perl, on the other hand, is a different animal. It took me some time and effort to learn to deal with regex-es, even after 20 or 30 years of programming experience, and even so, I never wrote more than few scripts in Perl (and I consider myself a very strong programmer in C, many flavors of assembler, Pascal, Fortran, Basic, Lisp). Of course, your mileage may vary, some people here (like Chalsall and DanaJ, who both of them eat Perl on butter every morning for breakfast, I assume) will tell you a different story.

But you have to try first. While you don't buy that lottery ticket, you can't win.

jzakiya · 2020-09-10, 17:54

To test the correctness of your implementation, first search for known large Twins (I assume that's what your looking for) to verify it finds them. Once you know the structure of the program is correct you can use any generator you want, dependent upon the capacity of your hardware to accommodate it.

If you use P23 or P29 you ideally want as many parallel threads as possible. GPUs would be very nice to use in this case, though a Super Computer would be the most ideal platform, more for its memory capacity than just pure speed and threads.

If you are concerned about speed, you need to use a compiled language that has good/mature multi-threading capability, though you can use Perl, etc, to code a proof-of-concept design to get working. All my original coding was done in Ruby, which allowed my to easily and quickly play with different implementations. I then translated that code into Rust, Nim, Crystal, and D multi-threaded versions, and tested their results to Ruby.

First, study my code to know exactly what and why its doing. Then start slow. Know what and why the results should be at each stage of your code for each section. The algorithm is very simple, if you understand it. Once you do, you can run it on any platform in your language(s) of choice.

If you need help post code on git[hub|lab], or a gist, or email me.

jzakiya · 2020-10-24, 14:20

There's a Rust forum post (2020/10/22) about a package to use Rust on GPUs.

https://users.rust-lang.org/t/introd...-gpu-0-1/50499

I don't have a GPU, so I don't have the hardware to play with it.
For those who do, this package should (?) provide the basics to implement the algorithm on GPUs, which (if properly done) increase performance significantly, while extending the number space range too.

https://github.com/EmbarkStudios/rus...eases/tag/v0.1

jzakiya · 2021-08-14, 17:33

This is the 1 year anniversary from the posting of the current paper so I wanted to update the twinprimes code implementations that have occurred in 2021.

The Rust implementation is the fastest, by a good amount compared to the others.

Rust
https://gist.github.com/jzakiya/b96b...eb3f35eb437225

Nim & C++ have comparable speed as I used GCC to compile both, though Nim can also use Clang, which produces a smaller binary, but not generally as fast (at least when I used previous versions, haven't used latest).

Nim
https://gist.github.com/jzakiya/6c7e...dd62e3e3b2341e

C++
https://gist.github.com/jzakiya/fa76...599983be175a3f

D
https://gist.github.com/jzakiya/ae93...c7f97ff8ad0f61

Go and Crystal (current 1.1.1) don't have a true parallel processing model, but do concurrency. Both of these implementation work (produce correct output values of twinprimes), but are slower compared to the above versions. They both have memory use issues, and can eat through system mem as input values increase.

The Go version is particularly bad at eating memory, but I was told that could be fixed by using modules with newest versions. If anyone wants to update it to make it better please do.

Crystal
https://gist.github.com/jzakiya/2b65...792f16c63a8ac4

Go
https://gist.github.com/jzakiya/fbc7...0ff7c2476373d9

There's also a Java version done by someone else that was posted earlier in this thread.

There are some possible architectural tweaks to use system threads more efficiently that I haven't been able to pursue yet, but when I get the time I'll see if my ideas on them will produce faster results.

FYI, with very minor changes, this code will also find Cousin Primes (prime pairs that differ by 4), since all you mostly have to do is use the residue pairs that differ by 4, than differ by 2 (the number of those residue pairs are the same as the number for twinprime residue pairs.)

jzakiya · 2021-08-20, 01:07

FYI, I just found and corrected a subtle variable size error, so please use updated C++ version for 2021/8/19.

jzakiya · 2021-08-21, 17:58

Found and corrected in the Crystal version a subtle variable Typing error for one variable.
The Crystal version now works over the full 64-bit range, but repeats a runtime WARNING about allocation of large blocks of memory for very large u64 inputs. Will see if I can get them to fix that (current is 1.1.1).

Again, Crystal currently doesn't do "true" parallelism (it's more like Go), so it doesn't have as good performance as Rust, Nim, and C++ versions, yet.

jzakiya · 2021-08-21, 19:41

Update:

This is for Linux based systems. Crystal uses LLVM for its backend.
To suppress the encountered GC WARNING message use the directive: GC_LARGE_ALLOC_WARN_INTERVAL=n

Set n > number of twinpair threads for the chosen Prime Generator (PG).
Example for P13 with 1485 twinpairs|threads:

$ GC_LARGE_ALLOC_WARN_INTERVAL=1500 CRYSTAL_WORKERS=8 ./twinprimes_ssoz 1299966672300000 1298760077778888

jzakiya · 2021-11-26, 20:18

I finally finished my video on Proof of the Twin Prime and Polignac's Conjectures I'd been working on awhile, based on the contents of my paper.

I made it accessible for the general public, using lots of pictures/graphs/visuals, and explain terminology.

I also I added more elementary stuff, and a simple deterministic primality test as well.
It should be much more user friendly than the paper, for all.

If I get the time, I'll turn more of my papers into videos, including construction of my sieves.
I'm also thinking of creating a whole video course based on them, but that will take much more time and work.

(Simplest) Proof of the Twin Primes and Polignac's Conjectures
https://www.youtube.com/watch?v=HCUiPknHtfY

Jabari Zakiya

paulunderwood · 2021-11-26, 21:22

I don't know about what you are driving at, but isn't a bit like "Goldbach" -- strong numerical evidence but no proof?

Anyway here is an interesting youtube video on prime gaps which sounds related...

jzakiya · 2021-11-26, 22:06

That video is only related to my video in that it also talks about prime gaps.

I show, using Prime Generator Theory (PGT), and Prime Generators (PGs), the systematic nature of how and why the prime gaps exist, and their distribution.

The bottom line is, using PGT you see there can never be a last prime pair for any gap size.

jzakiya · 2022-06-14, 23:20

I just released a new paper explaining in detail the math and software for the Twin|Cousin Primes SSoZ algorithms.
I started writing it in December 2021 and finished and released it a few days ago.
Here's a link to it, and I've also attached it.

Twin Primes Segmented Sieve of Zakiya (SSoZ) Explained
https://www.academia.edu/81206391/Tw...SSoZ_Explained

I provide code for their implementations in 6 languages: D, GO, C++, Nim, Rust, Crystal

Hopefully, people now will be able to implement it into any language of choice.
I'd love people to show me their versions, whether improvements of the ones given, and|or for different languages.

I'd also like to see benchmarks for other hardware.
Someone ran the Crystal code on an Apple M1, and it blew away times for the Intel and AMD systems I used.

Either way, I'd love feedback, and any questions.

2021-11-26, 20:18	#63
jzakiya Jul 2014 60₁₀ Posts	I finally finished my video on Proof of the Twin Prime and Polignac's Conjectures I'd been working on awhile, based on the contents of my paper. I made it accessible for the general public, using lots of pictures/graphs/visuals, and explain terminology. I also I added more elementary stuff, and a simple deterministic primality test as well. It should be much more user friendly than the paper, for all. If I get the time, I'll turn more of my papers into videos, including construction of my sieves. I'm also thinking of creating a whole video course based on them, but that will take much more time and work. (Simplest) Proof of the Twin Primes and Polignac's Conjectures https://www.youtube.com/watch?v=HCUiPknHtfY Jabari Zakiya Last fiddled with by jzakiya on 2021-11-26 at 20:19

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Twin Prime Constellations	robert44444uk	Prime Gap Searches	45	2022-02-24 18:28
How do you efficiently sieve for prime 3/4-tuples?	Puzzle-Peter	Software	156	2019-06-03 20:19
find very easy twin prime in the infamy twin primes	hal1se	Miscellaneous Math	13	2018-11-05 16:34
Highest Prime is also a twin prime... NOT	hydeer	Lone Mersenne Hunters	9	2018-04-03 22:54
Twin Prime Days, Prime Day Clusters	cuBerBruce	Puzzles	3	2014-12-01 18:15

2020-09-10, 17:54	#57
jzakiya Jul 2014 2²·3·5 Posts	To test the correctness of your implementation, first search for known large Twins (I assume that's what your looking for) to verify it finds them. Once you know the structure of the program is correct you can use any generator you want, dependent upon the capacity of your hardware to accommodate it. If you use P23 or P29 you ideally want as many parallel threads as possible. GPUs would be very nice to use in this case, though a Super Computer would be the most ideal platform, more for its memory capacity than just pure speed and threads. If you are concerned about speed, you need to use a compiled language that has good/mature multi-threading capability, though you can use Perl, etc, to code a proof-of-concept design to get working. All my original coding was done in Ruby, which allowed my to easily and quickly play with different implementations. I then translated that code into Rust, Nim, Crystal, and D multi-threaded versions, and tested their results to Ruby. First, study my code to know exactly what and why its doing. Then start slow. Know what and why the results should be at each stage of your code for each section. The algorithm is very simple, if you understand it. Once you do, you can run it on any platform in your language(s) of choice. If you need help post code on git[hub\|lab], or a gist, or email me.

2020-10-24, 14:20	#58
jzakiya Jul 2014 2²·3·5 Posts	There's a Rust forum post (2020/10/22) about a package to use Rust on GPUs. https://users.rust-lang.org/t/introd...-gpu-0-1/50499 I don't have a GPU, so I don't have the hardware to play with it. For those who do, this package should (?) provide the basics to implement the algorithm on GPUs, which (if properly done) increase performance significantly, while extending the number space range too. https://github.com/EmbarkStudios/rus...eases/tag/v0.1

2021-08-14, 17:33	#59
jzakiya Jul 2014 2²·3·5 Posts	This is the 1 year anniversary from the posting of the current paper so I wanted to update the twinprimes code implementations that have occurred in 2021. The Rust implementation is the fastest, by a good amount compared to the others. Rust https://gist.github.com/jzakiya/b96b...eb3f35eb437225 Nim & C++ have comparable speed as I used GCC to compile both, though Nim can also use Clang, which produces a smaller binary, but not generally as fast (at least when I used previous versions, haven't used latest). Nim https://gist.github.com/jzakiya/6c7e...dd62e3e3b2341e C++ https://gist.github.com/jzakiya/fa76...599983be175a3f D https://gist.github.com/jzakiya/ae93...c7f97ff8ad0f61 Go and Crystal (current 1.1.1) don't have a true parallel processing model, but do concurrency. Both of these implementation work (produce correct output values of twinprimes), but are slower compared to the above versions. They both have memory use issues, and can eat through system mem as input values increase. The Go version is particularly bad at eating memory, but I was told that could be fixed by using modules with newest versions. If anyone wants to update it to make it better please do. Crystal https://gist.github.com/jzakiya/2b65...792f16c63a8ac4 Go https://gist.github.com/jzakiya/fbc7...0ff7c2476373d9 There's also a Java version done by someone else that was posted earlier in this thread. There are some possible architectural tweaks to use system threads more efficiently that I haven't been able to pursue yet, but when I get the time I'll see if my ideas on them will produce faster results. FYI, with very minor changes, this code will also find Cousin Primes (prime pairs that differ by 4), since all you mostly have to do is use the residue pairs that differ by 4, than differ by 2 (the number of those residue pairs are the same as the number for twinprime residue pairs.)

2021-08-20, 01:07	#60
jzakiya Jul 2014 2²×3×5 Posts	FYI, I just found and corrected a subtle variable size error, so please use updated C++ version for 2021/8/19.

2021-08-21, 17:58	#61
jzakiya Jul 2014 60₁₀ Posts	Found and corrected in the Crystal version a subtle variable Typing error for one variable. The Crystal version now works over the full 64-bit range, but repeats a runtime WARNING about allocation of large blocks of memory for very large u64 inputs. Will see if I can get them to fix that (current is 1.1.1). Again, Crystal currently doesn't do "true" parallelism (it's more like Go), so it doesn't have as good performance as Rust, Nim, and C++ versions, yet.

2021-08-21, 19:41	#62
jzakiya Jul 2014 2²×3×5 Posts	Update: This is for Linux based systems. Crystal uses LLVM for its backend. To suppress the encountered GC WARNING message use the directive: GC_LARGE_ALLOC_WARN_INTERVAL=n Set n > number of twinpair threads for the chosen Prime Generator (PG). Example for P13 with 1485 twinpairs\|threads: $ GC_LARGE_ALLOC_WARN_INTERVAL=1500 CRYSTAL_WORKERS=8 ./twinprimes_ssoz 1299966672300000 1298760077778888

2021-11-26, 21:22	#64
paulunderwood Sep 2002 Database er0rr 2·2,243 Posts	I don't know about what you are driving at, but isn't a bit like "Goldbach" -- strong numerical evidence but no proof? Anyway here is an interesting youtube video on prime gaps which sounds related...

2021-11-26, 22:06	#65
jzakiya Jul 2014 3C₁₆ Posts	That video is only related to my video in that it also talks about prime gaps. I show, using Prime Generator Theory (PGT), and Prime Generators (PGs), the systematic nature of how and why the prime gaps exist, and their distribution. The bottom line is, using PGT you see there can never be a last prime pair for any gap size.