Dr Nicely's 1st occurrence Prime Gaps

[gjhiggins]

Originally Posted by MJansen

Hi Graham,
Ps why add an indicator for C?C/P?P/??? when you submit the gaps? ... The way to change the qualification is if someone of this community provides the qualification of the gap (more people should have that rol if possible). My 2 cents: add gaps unqualified, but check them collectively (if that is feasible!)

The feasibility isn’t obvious at this stage. I’m acutely aware of the load on members imposed by migrating to Open Source tech (Git repos, Github, SQLite3 and relational tables) and I’m keen to limit to a minimum any actual representation changes to the hosted list which is why I'm tring to keep the mapping as simple and direct as possible, given the constraints.

year (an integer) --> I would prefer timestamp if possible

Again, I’m striving for directness of mapping between old and new, at least until a community-maintained version of the list gains some traction and persistence. Git preserves commit timestamps, so there's a backstop.

primedigits (an integer) --> this is a calculated field so it should not be submitted in principle

It’s a freebie static web site and there aren’t any compute resources available to recruit, so - as with calculating merits - it’s now an up-front community consensus thing. Tom did note that ultimately, the responsibility rests with the discoverer:

“In all cases, ultimate responsibility for the verification of a gap rests with the discoverer(s).”

It’s now a community decision as to how to play the tradeoff between effort and rigor.

Of course, none of the above precludes the community from subsequently following its own path, I’m merely confining myself to getting a manageable maintenance solution implemented in the first instance.

Cheers

Graham

[gjhiggins]

Hi all,

I've boiled the update process down to a minimum. Assuming you have a fork of the project repos (illustrated guide in Appendix A: https://primegap-list-project.github...how-to-update/) and a file of SQL statements of your updates (illustrated guide: https://primegap-list-project.github.../how-to-check/)

1. clone your Github fork locally and change directory to the clone
2. start the SQLite3 command-line application with a temporary, empty database (suggested: `tmp.db`)
3. read in the repository’s list of prime gaps expressed as SQL statements (`allgaps.sql`)
4. read in the new gaps/bettered merits expressed as SQL statements
5. dump the database as SQL statements to the file `allgaps.sql` (overwriting the old one)
6. commit the updated `allgaps.sql` to your local clone of the repository
7. push the changes back to your fork on Github.
8. use the Github web ui to issue a Pull Request on the main project repository (illustrated guide in Appendix B https://primegap-list-project.github...how-to-update/)

Actual (cross-platform) SQLite3 command-line example:

SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> .read allgaps.sql
sqlite> .read prime-gap-list-conversion-2019-12-06T01_02_55.318Z.sql
sqlite> .output allgaps.sql
sqlite> .dump
sqlite> .quit

That's as simple as I can get it, it's up to the community whether you can live with it.

It doesn't address the issue of checking and validating entries, given the constraints, that's something only members of the community can organise amongst themselves.

It also doesn't address the issue of keeping the website's CSV datafile up to date - but it's a relatively trivial matter of cloning the project website repos, dumping the latest data in CSV from SQLite3 and committing/pushing the changes back to the project repos. (I'll write it up as a post on the Github website).

Other solutions are i) publish and maintain the list here or on an associated wiki ii) for someone to step forward and carry on the service provided by Tom iii) fund an AWS instance and code up a more sophisticated service.

I'm on hand to help you with any problems you might encounter.

Cheers

Graham

[gjhiggins]

Oh, one thing I forgot to mention. There is a "lightweight" means of submitting - at a cost to project maintainers, if they are amenable - by using Github issues (illustrated guide https://primegap-list-project.github...-github-issue/).

Cheers


Graham

[gjhiggins]

Maintaining the list as a file of SQL statements does bring more accessibility.

You can download the latest list here:
https://github.com/primegap-list-pro...er/allgaps.sql

And, if you run the SQLIte3 command-line client, you can generate your own list of gaps/merits for the range you're working on (10000 - 20000) using the copy'n'pasta example below

.mode list
.separator ','
.output merits.txt
SELECT gapsize, merit FROM gaps WHERE gapsize BETWEEN 10000 and 20000 ORDER BY gapsize;
.exit

I created a news post: https://primegap-list-project.github...how-to-update/

Cheers

Graham

[MJansen]

Hi Graham,


appreciated again! I will try somewhere next week and see how far I will come


Kind regards
Michiel

Originally Posted by gjhiggins

Hi all,

I've boiled the update process down to a minimum. Assuming you have a fork of the project repos (illustrated guide in Appendix A: https://primegap-list-project.github...how-to-update/) and a file of SQL statements of your updates (illustrated guide: https://primegap-list-project.github.../how-to-check/)

1. clone your Github fork locally and change directory to the clone
2. start the SQLite3 command-line application with a temporary, empty database (suggested: `tmp.db`)
3. read in the repository’s list of prime gaps expressed as SQL statements (`allgaps.sql`)
4. read in the new gaps/bettered merits expressed as SQL statements
5. dump the database as SQL statements to the file `allgaps.sql` (overwriting the old one)
6. commit the updated `allgaps.sql` to your local clone of the repository
7. push the changes back to your fork on Github.
8. use the Github web ui to issue a Pull Request on the main project repository (illustrated guide in Appendix B https://primegap-list-project.github...how-to-update/)

Actual (cross-platform) SQLite3 command-line example:

SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> .read allgaps.sql
sqlite> .read prime-gap-list-conversion-2019-12-06T01_02_55.318Z.sql
sqlite> .output allgaps.sql
sqlite> .dump
sqlite> .quit

That's as simple as I can get it, it's up to the community whether you can live with it.

It doesn't address the issue of checking and validating entries, given the constraints, that's something only members of the community can organise amongst themselves.

It also doesn't address the issue of keeping the website's CSV datafile up to date - but it's a relatively trivial matter of cloning the project website repos, dumping the latest data in CSV from SQLite3 and committing/pushing the changes back to the project repos. (I'll write it up as a post on the Github website).

Other solutions are i) publish and maintain the list here or on an associated wiki ii) for someone to step forward and carry on the service provided by Tom iii) fund an AWS instance and code up a more sophisticated service.

I'm on hand to help you with any problems you might encounter.

Cheers

Graham

[robert44444uk]

I developed a rough perl code for checking gaps that are deficient primorials in Nicely format that are >= 100000. I'm no expert at using the split function, but Nicely format is not very helpful as it contains variable numbers of blank spaces and blank spaces at the start for gaps <100000, and it has a number of operators such as / and * which are harder to parse. I'm sure someone could write the code quite efficiently!

I'm not sure if this is very fast, I'll do a check and see what comes of it - UPDATE it took 107 minutes for the first gap, compared to over 1/2 a day for cglp4

I can state categorically, that CSV is the way to go, going forward, then we can drop cglp4 entirely!

#!/usr/bin/env perl
use warnings;
use strict;
use Timer::Runtime;
use Math::GMPz;
use Math::BigFloat lib=>"GMP";
use Math::Prime::Util qw/:all/;
use File::Slurp;
use v5.10;

$|=1;

my @start = read_file( 'test1.txt' ) ; 
chomp (@start);

for (my $k=0; $k <= scalar(@start)-1 ; $k++){
say $start[$k];
my @fields = split /\s+/, $start[$k];
my @output = split /\*/,$fields[6];
my $multiplier = $output[0];
my @smalleroutput = split /#/,$output[1];
my $primorial = $smalleroutput[0];
my @evensmaller = split /\//,$smalleroutput[1];
my @tiny = split /-/,$evensmaller[1];
my $divisor = $tiny[0];
my $minus = $tiny[1];
say $multiplier," ", $primorial," ", $divisor," ", $minus;
say $fields[5], " ", $fields[0];

my $prim = primorial($primorial);
$prim = Math::BigInt->new("$prim") unless ref($prim) eq 'Math::BigInt';
my ($sn, $rem) = $prim->copy->bdiv($divisor);
my $n = $sn*$multiplier;
my $startprime = prev_prime($n);
my $endprime = next_prime($n);
my $gap = $endprime-$startprime;
say $gap;
if ($gap == $fields[0]) {
say "gap is correct";
}
}

[robert44444uk]

I did a bit of cleaning up of the perl code (I got smart with the split function!) and made it appropriate for a CSV in the format:

3772,C,?,C,RobSmith,2019,27.44,60,2366225377*139#/46410-2962

The code took less than 5 seconds to check the record gaps that are in the test2.txt file.

#!/usr/bin/env perl
use warnings;
use strict;
use Timer::Runtime;
use Math::GMPz;
use Math::BigFloat lib=>"GMP";
use Math::Prime::Util qw/:all/;
use File::Slurp;
use v5.10;

$|=1;

my @start = read_file( 'test2.txt' ) ; 
chomp (@start);
for (my $k=0; $k <= scalar(@start)-1 ; $k++){
my @fields = split /,/, $start[$k];
my ($multiplier,$primorial,$nothing,$divisor,$minus) = split /\*|#|\/|-/,$fields[8];

my $prim = primorial($primorial);
$prim = Math::BigInt->new("$prim") unless ref($prim) eq 'Math::BigInt';
my ($sn, $rem) = $prim->copy->bdiv($divisor);
my $n = $sn*$multiplier;
my $startprime = prev_prime($n);
my $endprime = next_prime($n);
my $gap = $endprime-$startprime;
say "calcuated gap following"," ",$fields[8]," ="," ", $gap;
if ($gap == $fields[0]) {
say "input gap is confirmed";
}
}

[robert44444uk]

BTW, Dr Nicely's university has taken the site and reposted it:

https://faculty.lynchburg.edu/~nicely/gaps/gaplist.html

[MJansen]

Hi Graham,


I was trying to follow your instructions and looked at the illustrated guide, but must have missed the part you refer to in step 1: clone your Github fork locally and change directory to the clone. I have to admit that I am totally clueless as to what that implies, could you help out?

I made a text file in the format you showed at the illustrated guide (136098,0,C,?,P,Toni_Key,2016,16.37,3610,"1500031*8431#/41910 - 97126")

The text file has 456 improvements on the data Tom published last (august 12th 2019 if I am correct). BTW this does not mean sombody else has improved sooner on these gaps. But this data can be used for testing.



Further, where can I find SQLlite3? Do you have a link? And what does dump the database mean? And pushing changes? I apologize for the noob questions, but this is all new to me and not very intuitive.

Kind regards
Michiel Jansen

Originally Posted by gjhiggins

Hi all,

I've boiled the update process down to a minimum. Assuming you have a fork of the project repos (illustrated guide in Appendix A: https://primegap-list-project.github...how-to-update/) and a file of SQL statements of your updates (illustrated guide: https://primegap-list-project.github.../how-to-check/)

1. clone your Github fork locally and change directory to the clone
2. start the SQLite3 command-line application with a temporary, empty database (suggested: `tmp.db`)
3. read in the repository’s list of prime gaps expressed as SQL statements (`allgaps.sql`)
4. read in the new gaps/bettered merits expressed as SQL statements
5. dump the database as SQL statements to the file `allgaps.sql` (overwriting the old one)
6. commit the updated `allgaps.sql` to your local clone of the repository
7. push the changes back to your fork on Github.
8. use the Github web ui to issue a Pull Request on the main project repository (illustrated guide in Appendix B https://primegap-list-project.github...how-to-update/)

Actual (cross-platform) SQLite3 command-line example:

SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> .read allgaps.sql
sqlite> .read prime-gap-list-conversion-2019-12-06T01_02_55.318Z.sql
sqlite> .output allgaps.sql
sqlite> .dump
sqlite> .quit

That's as simple as I can get it, it's up to the community whether you can live with it.

It doesn't address the issue of checking and validating entries, given the constraints, that's something only members of the community can organise amongst themselves.

It also doesn't address the issue of keeping the website's CSV datafile up to date - but it's a relatively trivial matter of cloning the project website repos, dumping the latest data in CSV from SQLite3 and committing/pushing the changes back to the project repos. (I'll write it up as a post on the Github website).

Other solutions are i) publish and maintain the list here or on an associated wiki ii) for someone to step forward and carry on the service provided by Tom iii) fund an AWS instance and code up a more sophisticated service.

I'm on hand to help you with any problems you might encounter.

Cheers

Graham

[rudy235]

Originally Posted by robert44444uk

BTW, Dr Nicely's university has taken the site and reposted it:

https://faculty.lynchburg.edu/~nicely/gaps/gaplist.html

I love it!

[storm5510]

Originally Posted by rudy235

NEW prime gap results

Last Updated 0600 GMT 12 August 2019

All gaps 1-1998 remain unchanged

It seems many here are discussing a SQL database, and what should be included and omitted. JSON is becoming popular on Primenet. What not use it instead? It may make your results more compatible.

I have started my own search for 2000 using code I wrote. I have it filtering for anything GEQ 500, just so I can see it move on the screen once in a while. It is not at all efficient so it may take a while. I am in no hurry.