Re-evaluate e_value
 

Since a few years now, GPU-assisted poly search is the only viable tool to find "good" poly. And almost every time, in the poly search thread we find "outlier" far better than the supposed e_value. Maybe it is time to re-evaluate the min_evalue criteria. i don't know, 30 % of the way between the current number and the best poly score we have availlable in the thread?

This varies substantially by input size; in the mid 150s, it's not easy to exceed the low end of the "expected range". Do you know of a record that exceeds the high end of the "expected range"?

Or are you referring to the minimum e-value that causes a poly to be written to the .p file? That can be controlled at the command line, not sure it needs changing in the software.

I tend to look only at [url=http://www.mersenneforum.org/showpost.php?p=478855&postcount=86]this table[/url] which lists all the high water marks found to date. I never use the suggested minimums produced by msieve, though I rarely run personal poly searches anymore

[QUOTE=swellman;489902]I tend to look only at [URL="http://www.mersenneforum.org/showpost.php?p=478855&postcount=86"]this table[/URL] which lists all the high water marks found to date. I never use the suggested minimums produced by msieve, though I rarely run personal poly searches anymore[/QUOTE]
This table produces a great linear fit
log[SUB]10[/SUB] e = -0.0634 sz - 1.6388
[COLOR=black]R[SUP]²[/SUP] = 0.9991[/COLOR]

With a couple of outliers removed, a slightly better fit.

You can put it in msieve-code-r1022-trunk/gnfs/poly/poly_skew.c:250
and recompile
[CODE] double e0 = (params->digits >= 121) ?
[COLOR=DarkRed](0.0635 * params->digits + 1.608) :[/COLOR]
(0.0526 * params->digits + 3.23);
if (degree == 4)[/CODE]