Some CRUS stats

[rogue]

Originally Posted by gd_barnes

A new problem has popped up. I just added a prime found by Mark and removed that k for R45. There were no changes to the testing limits. It now shows up on the unproven conjectures page here with a relative difficulty of -5 and an "n per 25000" of -2.

An old problem still exists. R63 still shows a relative difiiculty and an "n per 25000" of 0.

R63 might be hard to fix because I suspect that the large number of k is behind the problem. I doubt many people are interested in working on it. As for R45, it is probably due to something in the HTML, but I won't know until I get a chance to look at it.

[gd_barnes]

Originally Posted by rogue

R63 might be hard to fix because I suspect that the large number of k is behind the problem. I doubt many people are interested in working on it. As for R45, it is probably due to something in the HTML, but I won't know until I get a chance to look at it.

OK could you change it to where R63 shows a difficulty of something huge like 999999999 or 1e9? That way it will default to the bottom on a sort by difficulty. Programmatically I'm thinking that if the program can't figure out the difficulty because of too many k's, just default to some huge value like that.

I manually looked at the HTML tags for R45 and nothing looked out of the ordinary. But of course I could have missed something.

[rogue]

I believe that the attached will fix the problem. The script was trimming the trailing character from the remaining k, thus sending 1009*45^n-1 to srsieve, which balked because that number is always even. It is likely that other bases have the incorrect weight/difficulty because of this. I don't think it will change those values much. I will rerun them tonight and compare the output to see what would change.

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.

[rogue]

I've verified that the updated script produces more correct output. The conjectures that are incorrect are R45, R378, and R972 on the Riesel side and S46, S48, S53, S163, S171, S410, and S1017 on the Sierpinski side. Just delete the rows from those conjectures from the respective weights/difficulties files and they will be recomputed. Of course you want to do that after you updated the script.

[gd_barnes]

Well, that did the trick for those bases. But I've discovered several more bases with issues:

1. R36 "n per 25000" was identical to R35 at 407265. This could not be right because R35 has 562 k's remaining and R36 has only 46 k's remaining.

2. R2 "n per 25000" is way too low for conjectures with similar #'s of k's remaining. With 57 k's remaining, the "n per 25000" is only 5573. All other Riesel conjectures with 50 to 60 k's remaining have a value of between 30000 and 65000.

3. S2 and S2 2nd conj have an "n per 25000" that is also way too low.

Thinking that your new code might have fixed the problems, I removed these bases from the riesel_ and sierpinski_difficulty.txt files. They were not in the corresponding weights files. I then waited for the hourly update. Here is what happened:

1. R36 did not calculate at all. It now has the same problem as R63 did. It has an "n per 25000" of -2.

2. R2, S2, and S2 2nd conj still calculated the same incorretly low values for "n per 25000".

To give you an idea of how far off S2 2nd conj is...with 31 k's remaining, it has a similar "n per 25000" as most bases with just 3-4 k's remaining.

I wonder if this is a similar problem as before...the k's are too large and they get truncated before being sent to srsieve. 3 of these problem bases have k's with 6 digits in them. S2 has 5-digit k's.

[gd_barnes]

Hum. I tried removing R35 and R36 from Riesel_difficulty.txt (instead of just R36 like in the last posting). R35 recomputed correctly as it always has. But R36 this time...picked up the "n per 25000" to be the same value as R35. So now...R36 is back to where it was before.

Bottom line: R36 will not compute correctly regardless of the situation.

[rogue]

I'm certain that the problem is in the script I've posted. I have seen some differences in behavior between gawk on Windows and gawk on OS X, but I don't know if that explains what you are seeing. I should have some time today to investigate further.

[rogue]

I fixed the script. It will address R36. As for R2 and S2, they appear to be correct.

srsieve 1.0.3 -- A sieve for integer sequences in n of the form k*b^n+c.
Read 57 sequences from input file `riesel2.in'.
srsieve started: 100001 <= n <= 110000, 3 <= p <= 1000000
Split 57 base 2 sequences into 89 base 2^24 subsequences.
Sieving 3 <= p <= 1000000 eliminated 565597 terms, 4403 remain.
Wrote 4403 terms for 57 sequences to srsieve format file `srsieve.out'.
srsieve stopped: at p=1000000 because --pmax was reached.

[gd_barnes]

Thanks Mark. That did it.

One more question: The "n per 25000" looks really high for both sides of base 2 even-n and odd-n. Could the program be sieving for all n instead? If so, programming it wouldn't be the easiest.

This may have been what mislead me into thinking that "regular" base 2 "n per 25000" was too low on both sides.

[gd_barnes]

Well...isn't this something: S53 has the same problem as R36 did before. R36 was picking up the "n per 25000" from R35. Of course that is now fixed. So I just now went back through and sorted by "n per 25000" looking for identical values from bases that were close together. I then saw that S53 is incorrectly picking up the same "n per 25000" as S48. So...I did the same thing as before: I deleted both S48 and S53 in the sierpinski_difficulty file, ran the script, and the "n per 25000" incorrectly stayed the same on both. I then deleted only the S53 line, ran the script, and the "n per 25000" on S53 came out as -2, the same as what happened before with R36 and telling me that there is something wrong with S53.

Bottom line: S53 has the exact same problem that R36 had before.

My coworkers used to give me programs to "break". They hated me. :-)

[gd_barnes]

On the S53 problem, I just now tried deleting S52 and S53 from the difficulty file. Interestingly, S53 picked up the "n per 25000" from S52 instead of S48. It had previously gotten it's value from S48 before because you had me delete those 2 bases when fixing the original problem that started all of this. So we can conclude the following:

If a base has a problem that causes it to return an "n per 25000" of -2 when deleted from the difficulty file all by itself; if it is instead deleted in addition to another lower base above it, it will pick up the "n per 25000" from that base instead. So it appears that after each base is computed, a variable needs to be cleared out.

Edit: Further testing and review of the S53 *.in temp file confirmed that it is truncating the 4-digit k's before sending them to srsieve. It makes me wonder why this only happens on this base. There are many other bases of similar nature. In particular S53 has from 1 to 4-digit k's and truncates while R45 has from 2 to 5-digit k's but works fine.