Re-evaluate e_value

[firejuggler]

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?

[VBCurtis]

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.

[swellman]

I tend to look only at this table 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

[Batalov]

Originally Posted by swellman

I tend to look only at this table 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

This table produces a great linear fit
log₁₀ e = -0.0634 sz - 1.6388
R^² = 0.9991

[Batalov]

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

               double e0 = (params->digits >= 121) ?
                                       (0.0635 * params->digits + 1.608) :
                                       (0.0526 * params->digits + 3.23);
               if (degree == 4)