Some CRUS stats

[rogue]

Originally Posted by gd_barnes

A little closer inspection of the "CRUS statistics and progress" page revealed a couple of problems with the Sierpinski side only of the 1st table labeled "Status summary by conjecture":

1. On the "base not 2^x" column, the total should be 1019 bases (vs. 1018).

2. On the "all bases" column, the total should be 1032 bases (vs. 1033).

Note that the column in #1 adds correctly, there is just a missing base somewhere. As for the column in #2, the addition is also incorrect. If you add down, it only totals 1031 (vs. 1033). Correcting the addition still leaves it one base short just like column #1. Then...subsequently correcting #1 should fully correct #2.

The bottom line is that we have the same number of "base not 2^x" bases on both sides (1019) but we have one more "base 2^x" bases on the Sierp side (13 vs. 12) due to the Sierp base 2 2nd conjecture.

The problem with the Sierpinski side is a parsing issue. You have:

<td>19167 k's remaining at n=2.5K.&nbsp; See k's remaining on reservations
page.</td>

in the html. Change that to this

<td>19167 k's remaining at n=2500.<br> See k's remaining on reservations page.</td>

and the problems will be fixed. There is only so much that the parsing logic can do to account for the html. I think it would be much easier to modify the html than to try to modify the scripts.

[gd_barnes]

Originally Posted by rogue

The problem with the Sierpinski side is a parsing issue. You have:

<td>19167 k's remaining at n=2.5K.&nbsp; See k's remaining on reservations
page.</td>

in the html. Change that to this

<td>19167 k's remaining at n=2500.<br> See k's remaining on reservations page.</td>

and the problems will be fixed. There is only so much that the parsing logic can do to account for the html. I think it would be much easier to modify the html than to try to modify the scripts.

That did it. Thanks. It's strange that it created both a missing base problem as well as an addition problem but the HTML change fixed both.

[Puzzle-Peter]

Originally Posted by rogue

For R63, I recommend change the line for R63 in riesel_difficulty.txt to this

63,63,299255,999999999

It won't try to recompute the value unless the number of remaining k changes.

I tried to resist, but it felt like fighting gravity...

28998004*63^10001-1 is prime

Back to business: I ran srsieve on the file of remaining k's with n=N=10001 and I got a result file that contained lines like

27338*63^n-1
10001
34226*63^n-1
37824*63^n-1
38986*63^n-1
10001
51868*63^n-1
10001

No candidate for some of the sequences but the "headline" remained which caused problems for srfile. I'm running srsieve 0.6.16 Windows XP 32bit. A lot of sequences were removed correctly and I don't see a pattern.

[gd_barnes]

Originally Posted by Puzzle-Peter

I tried to resist, but it felt like fighting gravity...

28998004*63^10001-1 is prime

Back to business: I ran srsieve on the file of remaining k's with n=N=10001 and I got a result file that contained lines like

27338*63^n-1
10001
34226*63^n-1
37824*63^n-1
38986*63^n-1
10001
51868*63^n-1
10001

No candidate for some of the sequences but the "headline" remained which caused problems for srfile. I'm running srsieve 0.6.16 Windows XP 32bit. A lot of sequences were removed correctly and I don't see a pattern.

Sorry...not gonna show that single prime and potentially annoy the stats program for a single prime out of nearly 300,000 k's remaining. What would happen is that it would try to recalculate the entire base, error out because of too many k's, and end up showing a 0 or -2 difficulty. Then I'd have to go in and manually put in a huge difficulty again. By the way, the 350000000 difficulty is a fairly accurate representation of its difficulty although it is an estimation. I took the average weight for all k's from S63, raised it slightly since R63 is only at n=10K vs. n=25K, and extrapolated it to R63.

I believe that the sieve file is what happens if you specified no type switch and it wrote it out to srsieve.out. My suggestion is to write it out to an ABCD file with the -a switch or to a NewPGen type file with the -G switch. It appears to get confused when there is no candidates for a k in a file in the generic "srsieve.out" formatted sieve file.

Regardless, I would never recommend sieving a single n at a time with the sr(x)sieve series of programs. It's far too inefficient. At least sieve 1000n. Likely more than 99.9% of all k will have a candidate that is not sieved out.

[Puzzle-Peter]

Originally Posted by gd_barnes

Regardless, I would never recommend sieving a single n at a time with the sr(x)sieve series of programs. It's far too inefficient.

I know, this was just for fun.Thanks anyway.

[rogue]

For S63 the list of remaining k is in a zip file. The script does not d/l that zip file and try to run srsieve against it. The script automatically assigns a default difficulty if it is unable to run srsieve.

[gd_barnes]

Originally Posted by rogue

For S63 the list of remaining k is in a zip file. The script does not d/l that zip file and try to run srsieve against it. The script automatically assigns a default difficulty if it is unable to run srsieve.

That's R63.

I know and even if all the k's were listed, I'm certain that srsieve could not handle the nearly 300,000 k's. I overroad the default "n per 25000" in the Riesel difficulty file with one that should be fairly accurate for R63.

[gd_barnes]

Mark,

Riesel base 1030 does not show up on the unproven page.


Gary

[rogue]

Originally Posted by gd_barnes

Mark,

Riesel base 1030 does not show up on the unproven page.

Gary

I had never noticed. In 12_proc_conjectures.txt, there is a line:

!/esti/ && !/TITLE/ {

change it to

{

TITLE is one of the tags getting parsed with k=1030 (because the two pages are concatenated) and the current code is ignoring that row. I haven't run all of the scripts to see if this introduces any problems, but if there are any, they should be easy to fix.

[gd_barnes]

That corrected the unproven problem but it has introduced some problems on the top 20 page. Take a look and you'll see them fairly quickly. There are zeros and greater than ">" signs in random locations.

[rogue]

With the change I suggested earlier today, conjectures where the web page has "no testing done" or "just started testing" are now being parsed rather than being clumped together as "not tested". I added extra logic to the 12_ script to handle those rows. In the process I decided to add a "just started" category for the stats page. I have collected all current scripts and posted them on my website and attached them here.