I'll pick up a polynomial for the C162 tonight, the one in post #220 unless something better trickles in.

[code]
R0: -9958502607381088781671996613155
R1: 143221703738676211
A0: -1535697080059276964417309512945888134324
A1: 2485770470444143530176565977570027
A2: 212731110894034066222615065
A3: -137504378769271273383
A4: -6007639133392
A5: 1257732
skew 6402007.49, size 1.053e-015, alpha -7.666, combined = 1.164e-012 rroots = 5
[/code]
not better than #220 but a worthy opponent, right?

Unless the skew makes it way worse than mine, your score is slightly better. debrouxl, do you test sieve these? If so, could you report back which of the two does better?

[QUOTE=wombatman;353871]Unless the skew makes it way worse than mine, your score is slightly better. debrouxl, do you test sieve these? If so, could you report back which of the two does better?[/QUOTE]

The E-score includes effects of skew, in that higher scores usually sieve better (with the caveat that the score's prediction is +- 5% or so; a 1.12 and 1.16 should be test-sieved usually, though with NFS@home's firepower it may not be worth the trouble).

The catch, as I understand it, with skew is that the skew is a measure of the ratio of the dimensions of the sieve region; a higher skew means the siever works in a narrower rectangle, possibly resulting in the need for more special-q. So, all else equal, we choose lower-skew polys in order to (probably) need fewer special-q, which makes for a lower chance of setbacks or having to exceed the special-q range that sieves well.

Since we know higher A5 values produce lower skew, the logic is that we can avoid having to consider this tradeoff overall by just not searching low A5 values. However, it seems pretty common to find a nice poly in those lower values (for reasons I do not know enough to understand).

Part of the reason I suggested we less-experienced folk do months of poly selection for the forum is to try to gain insight into these tradeoffs, and I write things like this in hopes an expert will correct me where I'm mistaken.

Even if they do not test-sieve these two polys, I will consider doing so to see how it works and the results.

As someone who last took a math course (with Fourier transforms being the end-of-course material) approximately....5 or 6 years ago, I appreciate your writing out what your reasoning is. I think I understand what you're saying, and I would also be grateful for a better-versed forum member to come in and provide additional info/corrections.

I'll look forward to seeing what your test-sieving shows.

I test-sieved the polynomials from post #220 and post #222, and we have a clear winner :smile:

[code]# Post #220:
n: 123185130483506137603191442064883489372927504206113226437834768431648754408159660500479519543123321318633171550119649429370954650787254654692369907789231588824311
skew: 1853378.17
c0: 173005616341925019068425420358687999075
c1: 206061802204907426411915664451175
c2: -490930924636416636463430237
c3: -56469426027893147207
c4: 155360648044842
c5: 20703312
Y0: -5687267901887849117628057930336
Y1: 50226349167486893
type: gnfs
rlim: 67108863
alim: 67108863
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6

-> Q0=33554431.5, QSTEP=100000.
-> makeJobFile(): q0=33554431.5, q1=33654431.5.
-> makeJobFile(): Adjusted to q0=33554431.5, q1=33654431.5.
-> Lattice sieving algebraic q-values from q=33554431.5 to 33654431.
=> "../gnfs-lasieve4I14e" -k -o spairs.out -v -n0 -a C162_3408_1361.job
gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision: 412 $
FBsize 2062450+0 (deg 5), 3957808+0 (deg 1)
total yield: 1573, q=33555283 (0.13668 sec/rel) ^C[/code]

Polynomial from post #222:
[code]# Post #222
n: 123185130483506137603191442064883489372927504206113226437834768431648754408159660500479519543123321318633171550119649429370954650787254654692369907789231588824311
skew: 6402007.49
c0: -1535697080059276964417309512945888134324
c1: 2485770470444143530176565977570027
c2: 212731110894034066222615065
c3: -137504378769271273383
c4: -6007639133392
c5: 1257732
Y0: -9958502607381088781671996613155
Y1: 143221703738676211
type: gnfs
rlim: 67108863
alim: 67108863
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6

-> Q0=33554431.5, QSTEP=100000.
-> makeJobFile(): q0=33554431.5, q1=33654431.5.
-> makeJobFile(): Adjusted to q0=33554431.5, q1=33654431.5.
-> Lattice sieving algebraic q-values from q=33554431.5 to 33654431.
=> "../gnfs-lasieve4I14e" -k -o spairs.out -v -n0 -a C162_3408_1361.job
gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision: 412 $
FBsize 2064657+0 (deg 5), 3957808+0 (deg 1)
total yield: 1710, q=33555271 (0.12154 sec/rel) ^C[/code]

The 5th degree coefficient of the better polynomial is more than an order of magnitude lower.

Interesting that the lower C5 gives a better result!

It's all about the combined E-score. VBCurtis post [URL="http://mersenneforum.org/showpost.php?p=353891&postcount=224"]#224[/URL] was very informative, at least to me. :smile:

[QUOTE=VBCurtis;353891]The E-score includes ....[/QUOTE]
+1 :goodposting:

The test-sieve done here (in #226) shows that in this case, a poly with score 4% better sieved ~13% better, at least at this one special-q. Debrouxl was kind enough to post his parameter list, allowing us to compare the polys across the typical expected range of special-q values (according to T Mack, from 1/3rd rlim to rlim).

I claimed +- 5% for the E-score's accuracy; in this case, the 1.16 poly performed better than its score, while the 1.12 may have performed worse. Recall the E-score is an integral over the expected sieve region- but our actual sieve region may not be the region used by the E-score (right?).

If you head over to the Aliqueit forum, you'll find some team-sieve threads, for example [url]http://mersenneforum.org/showthread.php?t=18478[/url]. Those threads have explicit instructions for how to call the siever directly from the command line, without use of factmsieve or yafu. We interested parties should test-sieve 0.5k ranges (that's -c 500) with -f set anywhere from 22M to 67M. If we test at every 5M, we'll get a very detailed picture of the relative performance of these two polys. It's not that we need it for this one instance, but this is a terrific opportunity to learn to use the tools.

If you try this, take note of the difference between production per special-q (the number of relations you get out of your -c 1000 range) and the production per second reported by lasieve. If my elementary grasp of skew is correct, the better poly will have a lower production per 500 range even while it's better per second.

If you try it, post your selected -f starting spot, and the time per relation for each poly.

I may just have to do this overnight...I'll post what I get some time tomorrow!