Prime gap records

[mart_r]

Originally Posted by MJansen

Ps why the fascination with the very large dividers? For me they seem too much of a (very rare) hit or (usual) miss, and after sieving and PRP-ing these huge numbers, it is rather annoying not having anything to show for ;-)

As you can see in the big lists, I do have some gaps to show
And I'm aiming for the Top Ten in the list of discoverers.
The initial motivation to work in that range came from an idea how to work primarily with OpenPFGW while keeping the number of redundant PRP tests low.

Edit: Or did you mean my suggestions for a 10M gap? That's just a fancy idea for a future endeavor. :)

[MJansen]

Originally Posted by mart_r

As you can see in the big lists, I do have some gaps to show
And I'm aiming for the Top Ten in the list of discoverers.
The initial motivation to work in that range came from an idea how to work primarily with OpenPFGW while keeping the number of redundant PRP tests low.

Edit: Or did you mean my suggestions for a 10M gap? That's just a fancy idea for a future endeavor. :)

Hi Mart, was indeed the 10M gap I was referring to! Just the practical side of hunting very big gaps that keeps me from deviating from the usual dividers but otherwise interesting if it lowers the amount of redundant PRP's!

[SethTro]

Andrew Usher found a small bug in one of the records lists: https://primegap-list-project.github...gh-watermarks/ lines 244 and 245 are out of order because 245 is slightly smaller.

244 N 3397520 PRP97234 = 224423#/102233201070 - 1888326 15.1751 Martin Raab 2021
245 N 4397298 PRP97234 = 224423#/107371994730 - 2375864 19.6406 Martin Raab 2021

These are both 97234 digit numbers but one starts with 280 and the other starts with 267.

Sadly this is a hard to fix precision issue. The code sorts by log(start) computed from gap / merit (parsing the numbers exactly isn't easy in javascript). Merit is saved with 6 digits of precision in the CSV file. In this case the correct answer for these rows are log(start) = 223888.28950149997 vs 223888.2404585973 but the code (with 6 digits of precision from the CSV) computes 223887.81622526376 vs 223888.1704224922 (which sort incorrectly).

The "easy" fix would be to increase precision one digit and kick the can down the road for a while. Alternatively I could add some post-processing to the CSV to have an integer size rank (computed in python where I have the exact numbers).

A higher priority task is to figure out how to cache the CSV file when browsing the github site so it only loads the X mb file 1 time. EDIT: This is already done, the javascript is just slow sorting 100,000 lines.

[SethTro]

I made a change to the javascript that should speedup page rendering by ~30%

https://github.com/primegap-list-pro...62262e03bd6c4f

$.csv.toArrays takes on the order of 1 second which is now the bottleneck for faster rendering.

[SethTro]

I swapped to using Papa Parser which is 3-6x faster and now the pages are blazing fast (~300ms) after the first load of the CSV files.

https://github.com/primegap-list-pro...c78ecccf133cdd

[mart_r]

Originally Posted by SethTro

I swapped to using Papa Parser which is 3-6x faster and now the pages are blazing fast (~300ms) after the first load of the CSV files.

https://github.com/primegap-list-pro...c78ecccf133cdd

A question: some of my gaps from April/May are still queued at Cloudygo (doublechecked, but not yet appearing in the main lists). Is that something you do manually?

[SethTro]

Fixed now! 5 commits had been submitted, to cloudygo, but not uploaded because of an outdated ssh key.

[mart_r]

Originally Posted by SethTro

Fixed now!

Awesome Thanks!