Dr Nicely's 1st occurrence Prime Gaps

[gjhiggins]

Originally Posted by MJansen

May I suggest a practical test, based on a gap I found recently (the last gap with merit below 25 in the range 10.000-14.998:
13918 10645257227*547#/30 - 7804

Can't do that I'm afraid. The fact that it's a (free) static website means that there's no active processing other than javascript in the browser, so there's no means of evaluating the expression in order to derive the length of the starting prime. And anyway, cgpl4 neither checks nor reports the measure of merit. Thomas must have been using some other means of calculating/validating the measure of merit. I've no clue how to check the merit, I've been pulling the value out of the Gapcoin blockchain and wouldn't know where to start. Now it's me that needs the idiot's guide :)


I guess Nicely format or the same data in comma-separated format is all that can be handled.

PS Would it be possible to add a text file with a few hundred gaps like these, to the site that can be read by the database? Or is it only possible to add one gap at the time?

Yes, that is the intention. I'm currently trialling it with 451 Gapcoin records (in Nicely format) which should be an adequate test.

btw, www.trnicely.net is apparently no longer being served -- and by extension, neither is allgaps.dat. However, as far as I could tell, the entire contents have been captured by archive.org (https://web.archive.org/web/*/http:/...net/index.html)

Cheers

Graham

[ATH]

I also have a copy of the site if anything is missing.

[robert44444uk]

Originally Posted by gjhiggins

Can't do that I'm afraid. The fact that it's a (free) static website means that there's no active processing other than javascript in the browser, so there's no means of evaluating the expression in order to derive the length of the starting prime. And anyway, cgpl4 neither checks nor reports the measure of merit. Thomas must have been using some other means of calculating/validating the measure of merit. I've no clue how to check the merit, I've been pulling the value out of the Gapcoin blockchain and wouldn't know where to start. Now it's me that needs the idiot's guide :)

Hi Graham

I think all of the gap searchers know how to evaluate the start prime, the length of the gap and measure the merit of the gap, so I don't think that is an issue. Searchers could be required to do this before submitting a gap and provide the record in required format, whatever you decide that should be. I'd be comfortable with CSV.

Searchers can provide other database fields as required as well.

The question really comes down to whether the submitted gap of a given length is of higher merit than the existing record, and whether any query that is carried out on the database will provide the largest merit for the gap of a given length. It is inevitable that in a submission of 1000 gap record candidates, say, that there would be instances where the gap submitted is of lower merit than the record, if the submission is processed after another person's submission that contained a higher merit for that gap length.

[gjhiggins]

Originally Posted by robert44444uk

I think all of the gap searchers know how to evaluate the start prime, the length of the gap and measure the merit of the gap, so I don't think that is an issue. Searchers could be required to do this before submitting a gap and provide the record in required format, whatever you decide that should be. I'd be comfortable with CSV.

That's useful to know. I'm working on a web page which will accept a block of pasted CSV, run the checks (see below) and output the appropriate SQL statements for copying locally.

Searchers can provide other database fields as required as well.

Better to be as minimalist as possible, just the standard 10-item datast will suffice:

1. gapsize (an integer),
2. ismax (integer 0 or 1)
3. primecat (fixed as "C"),
4. isfirst (either "?" or "F"),
5. primecert (either "C" or "?"),
6. discoverer (the extant abbreviation ""),
7. year (an integer),
8. merit (a float),
9. primedigits (an integer),
10. startprime (a string)

The question really comes down to whether the submitted gap of a given length is of higher merit than the existing record

I'm working on that at the moment. I have a script in Python which performs the check and renders SQL statements as appropriate. Two checks are needed, one for when there isn't an existing record gap (needs a SQL INSERT statement) and another for when an existing gap's merit is bettered (needs a SQL UPDATE statement).

Happily, SQLiteBrowser's "Execute SQL" tab offers a "Read file" button which reads a local file of SQL statements (as created by my Python script) into the form, ready for the "Execute" button to be clicked to update the db, ready for exporting as SQL. It didn't object when I fed it a file of 500-odd SQL statements that I milled for the Gapcoin entries, so that does seem to be a promisingly viable path.

(I'll also flag a possible issue-for-the-future in that a more complex check may be required - whether a better merit for a C?? trumps a lower merit for a C?C)

I've switched operations from https://github.com/gjhiggins/prime-gap-list (and https://gjhiggins.github.io) to https://github.com/primegap-list-project/ (and https://primegap-list-project.github.io). If you can let me know your github identity, I can add you to the latter project team.

The site is currently rendering on https://primegap-list-project.github.io but the top20 lists are non-functioning atm.

This is because I am rewriting the top20 lists to use a CSV source instead of a SQL source. This is for a couple of reasons i) the allgaps.db is a binary and an inappropriate inclusion for github pages and ii) it enables me to dispense with the SQL-handling javascript library which is rather an expensive resource --- although the top20 lists were rendering okay on my mobile phone, the demands of the sql library were preventing the tables from rendering on my smart TV. That might sound a bit precious but if my telly can handle it, then most current web browsers will be able to as well.

Thus far I have converted the "key to abbreviations" page to use the "credits.csv" as a source: https://primegap-list-project.github.io/abbreviations/ but right now I'm concentrating on developing the CSV-to-SQL page.

I've also moved the project-specific posts to the _drafts folder which means they won't show up in the publicly-rendered site but do remain accessible via the github repos web ui: https://github.com/primegap-list-pro...master/_drafts - so the CSV formatted examples remain readily accessible as an aide memoir if needed.

Cheers

Graham

[robert44444uk]

Originally Posted by gjhiggins

Better to be as minimalist as possible, just the standard 10-item datast will suffice:

1. gapsize (an integer),
2. ismax (integer 0 or 1)
3. primecat (fixed as "C"),
4. isfirst (either "?" or "F"),
5. primecert (either "C" or "?"),
6. discoverer (the extant abbreviation ""),
7. year (an integer),
8. merit (a float),
9. primedigits (an integer),
10. startprime (a string)

If you can let me know your github identity, I can add you to the latter project team.

Hi Graham

I just noticed Dr Nicely's site is now down - looks like permanently. Well done those folks who have cloned it.

The problem with going for a stripped down submission is that there is an assumption that the linked fields are constant. For example, I have found gaps using software developed by R Gerbicz as part of a PGS coordinated search, as well as gaps using my own perl code, and sometimes based on gap generator programs developed by danaj. I would like to be able to distinguish these at the submission phase. Can I suggest an additional field "notes" with say up to 40 alpha, upper and lower case.

The "discoverer" field was limited to 8 alpha before, and I think it is more sensible to convert now to a longer alpha field with initial(s) or forename and surname, with upper case and lower case. Say 30 alpha.

I think we also need to allow "P" as a possible primecert - meaning probable prime

"merit" should not be float but a rounded 6 decimal number with trailing zeros if applicable, for example 35.678020. Reporting from the system can be a smaller number of decimals, but there should be a lower limit on what constitutes a new record and I think 6 decimals is adequate.

Regarding the database can we add month of the year as a 3 alpha, in the form Jan, Feb, etc? This would encourage more frequent submissions and a better sense for the rate of discovery.

Happy for others to comment and improve

My GitHub id is robert44444uk, same as mersenneforum

[Bobby Jacobs]

We could put the complete list of gaps on this site.

[robert44444uk]

Originally Posted by Bobby Jacobs

We could put the complete list of gaps on this site.

If you can store an infinite number of gaps

[gjhiggins]

Originally Posted by Bobby Jacobs

We could put the complete list of gaps on this site.

Good point. The last capture by archive.org was 21st May 2019 (https://web.archive.org/web/*/http:/...ps/allgaps.dat)


So archive.org doesn't have a capture of Tom Nicely’s update of August 2019 with Rob’s last additions and Tom’s site is no longer available. Fortunately, I have a copy from trnicely,net from late November.

I've added it to the repository but on principle, it should also be lodged here.


Cheers


Graham

[gjhiggins]

I created a draft post with a step-by-step illustration of how to check candidate new merits / gaps: https://github.com/primegap-list-project/primegap-list-project.github.io/blob/master/_drafts/2019-12-04-how-to-check.md


Oops, almost forgot to mention - it hates trailing newlines. If you try it out and it appears unresponsive to clicks, check if there's a trailing newline and if so delete it.



Cheers,

Graham

[gjhiggins]

Originally Posted by robert44444uk

For example, I have found gaps using software developed by R Gerbicz as part of a PGS coordinated search, as well as gaps using my own perl code, and sometimes based on gap generator programs developed by danaj. I would like to be able to distinguish these at the submission phase.

Tom already devised such a scheme, he varied the 8-character discoverer field as required and added a corresponding abbreviation key in the credits table. MJansen is a good example of exactly what you describe: https://primegap-list-project.github.io/abbreviations/

The "discoverer" field was limited to 8 alpha before, and I think it is more sensible to convert now to a longer alpha field with initial(s) or forename and surname, with upper case and lower case. Say 30 alpha.

That'd increase the size of the gaps table by (number of entries * (30 - 8)). Is why Tom used an abbreviation and provided a key. That scheme is preserved in the new regime.

I think we also need to allow "P" as a possible primecert - meaning probable prime

I did know that, it was just a brain fart. It's correct in the complete description of the data fields: https://primegap-list-project.github...d-data-fields/ There were a few '?'s earlier in the year but they've been resolved and there's only 'C' and 'P' at present. The state of play can checked with a SQL query https://github.com/primegap-list-pro...ding-primes.md

"merit" should not be float

Another brain fart. The actual datatype is a SQLite REAL. The spatial organisation of the Nicely format necessitates imposed limitations on precision whereas csv allows arbitrary precision up to the capacity of the application (sqlite3).

Regarding the database can we add month of the year as a 3 alpha, in the form Jan, Feb, etc? This would encourage more frequent submissions and a better sense for the rate of discovery.

The git commits have a timestamp. If that is seen as an acceptable proxy, it would obviate the necessity to expand the number of data fields. If not, I'll add it as a Github issue for subsequent implementation.

My GitHub id is robert44444uk

Terriff, I'm nearly there, the remaining task is to create the idiot’s^W guide.

Cheers

Graham

[MJansen]

Hi Graham,


really appreciate all your hard work! After december 16 I will have a few days off so I hope to participate more actively then.


Ps why add an indicator for C?C/P?P/??? when you submit the gaps? I would suggest to leave it completely from the gaps you submit (but have the database add a standard value of ???). 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!)


Delimited text files are absolutely fine by me. I would suggest:

1. gapsize (an integer)
2. discoverer (the extant abbreviation "")
3. year (an integer) --> I would prefer timestamp if possible
4. merit (a float)
5. primedigits (an integer) --> this is a calculated field so it should not be submitted in principle, but if that is easier, then no problem!
6. startprime (a string)

The string would look something like (pure fictional string!):
123456;"M.Jansen";#19:52 8-12-2019#;20,154231;7450;"2319*7213#/30030"


The other fields I would leave out of the submitted file/text string:

1. ismax (integer 0 or 1)
2. primecat (fixed as "C"),
3. isfirst (either "?" or "F"),
4. primecert (either "C" or "?"),

Kind regards
Michiel Jansen

Originally Posted by gjhiggins

Tom already devised such a scheme, he varied the 8-character discoverer field as required and added a corresponding abbreviation key in the credits table. MJansen is a good example of exactly what you describe: https://primegap-list-project.github.io/abbreviations/

That'd increase the size of the gaps table by (number of entries * (30 - 8)). Is why Tom used an abbreviation and provided a key. That scheme is preserved in the new regime.

I did know that, it was just a brain fart. It's correct in the complete description of the data fields: https://primegap-list-project.github...d-data-fields/ There were a few '?'s earlier in the year but they've been resolved and there's only 'C' and 'P' at present. The state of play can checked with a SQL query https://github.com/primegap-list-pro...ding-primes.md

Another brain fart. The actual datatype is a SQLite REAL. The spatial organisation of the Nicely format necessitates imposed limitations on precision whereas csv allows arbitrary precision up to the capacity of the application (sqlite3).

The git commits have a timestamp. If that is seen as an acceptable proxy, it would obviate the necessity to expand the number of data fields. If not, I'll add it as a Github issue for subsequent implementation.

Terriff, I'm nearly there, the remaining task is to create the idiot’s^W guide.

Cheers

Graham