better k weights

[Mini-Geek]

In thinking about low k's regarding this discussion, I thought I'd calculate the Nash weights of all the S6 k's. I did so, and surprisingly, found that k=97131 had a higher weight (250) than two others that really had about twice the candidates remaining (k=76441, weight 242, and k=50252, weight 243). Nash weights are calculated as the number of candidates remaining in n=100001-110000 after sieving to 511. In this case anyway, that isn't nearly enough to make a good representation of how many candidates you'll have to test (on two counts: some k's may have oft-repeated factors over 511, and that's not enough candidates, especially for lower k's, to have very accurate results; I suspect the first makes large inaccuracies like this one and the latter just makes for slightly noisier results). For comparison to try to get more real-world results, I also sieved the k's from n=400k-800k to P=1e6 and 10e6. To compensate for different depths and n ranges, I'm considering the ratios between these three different weights. The ratio between my two depths (1M and 10M) was only negligibly different (mean 0.8576, std. dev. 0.0069), but the ratio between the Nash weight and my test results varied wildly, from 8.54 at k=97131, then most around 18, and the highest at 20.17. The mean was 17.4264 and standard deviation in that ratio was 2.5567. This other result more closely matched the real-world result of k=97131 being about half the weight of 76441 and 50252.

In short, I submit that instead of Nash weights calculated as:
number of candidates remaining in n=100001-110000 after sieving to 511, for example, the srsieve command:
srsieve -n 100001 -N 110000 -P 511 "97131*6^n+1"
It would be far better to calculate weights as:
number of candidates remaining in n=400000-800000 after sieving to 1000000, (or perhaps even larger bounds for both, e.g. 100K-1M sieved to 10M or 100M) for example, the srsieve command:
srsieve -n 4e5 -N 8e5 -P 1e6 "97131*6^n+1"
If desired, we could divide the new weight by 18 to get a number on the approximately same scale as a Nash weight.

[rogue]

Originally Posted by Mini-Geek

In thinking about low k's regarding this discussion, I thought I'd calculate the Nash weights of all the S6 k's. I did so, and surprisingly, found that k=97131 had a higher weight (250) than two others that really had about twice the candidates remaining (k=76441, weight 242, and k=50252, weight 243). Nash weights are calculated as the number of candidates remaining in n=100001-110000 after sieving to 511. In this case anyway, that isn't nearly enough to make a good representation of how many candidates you'll have to test (on two counts: some k's may have oft-repeated factors over 511, and that's not enough candidates, especially for lower k's, to have very accurate results; I suspect the first makes large inaccuracies like this one and the latter just makes for slightly noisier results). For comparison to try to get more real-world results, I also sieved the k's from n=400k-800k to P=1e6 and 10e6. To compensate for different depths and n ranges, I'm considering the ratios between these three different weights. The ratio between my two depths (1M and 10M) was only negligibly different (mean 0.8576, std. dev. 0.0069), but the ratio between the Nash weight and my test results varied wildly, from 8.54 at k=97131, then most around 18, and the highest at 20.17. The mean was 17.4264 and standard deviation in that ratio was 2.5567. This other result more closely matched the real-world result of k=97131 being about half the weight of 76441 and 50252.

In short, I submit that instead of Nash weights calculated as:
number of candidates remaining in n=100001-110000 after sieving to 511, for example, the srsieve command:
srsieve -n 100001 -N 110000 -P 511 "97131*6^n+1"
It would be far better to calculate weights as:
number of candidates remaining in n=400000-800000 after sieving to 1000000, (or perhaps even larger bounds for both, e.g. 100K-1M sieved to 10M or 100M) for example, the srsieve command:
srsieve -n 4e5 -N 8e5 -P 1e6 "97131*6^n+1"
If desired, we could divide the new weight by 18 to get a number on the approximately same scale as a Nash weight.

I agree that the Nash weight is too inaccurate and that we need to make a change. Before deciding on a means by which we could do this, we need to decide how to accomplish a weight calculation that works well under all (or almost all) circumstances. Some criteria to consider are:

• cannot be easily skewed by combinations of k and b
• use sufficiently large numbers (at least 100,000 digits) to avoid too much skewing by small divisors
• use sufficiently large range of numbers (at least 100,000) to avoid too much skewing by factor density
• sieve deep enough to avoid skewing by choice of k or b
• potential to be used with other forms (primorials, GFNs, etc.)
• density is based upon a fixed size range

I suggest a range size of 10,000 for the last item because that makes computations much easier as users typically do ranges in multiples of 10,000. For the fourth item I see no reason why srsieve is the one program to generate such a number. Sieving of other forms (with their respective programs) will give an idea as to density of that form.