Yafu

[lorgix]

I have completed a "-psearch wide" on a c147.

#1. 9.293e-12
#2. 9.278
#3. 9.019
#4. 8.994
#5. 8.991
#6. 8.960
#7. 8.627
.
.
.
#17. 8.502

So if you want a comparison for a c147 you can do a "-psearch fast" on 43^137-1.

[bsquared]

Originally Posted by lorgix

I have completed a "-psearch wide" on a c147.

#1. 9.293e-12
#2. 9.278
#3. 9.019
#4. 8.994
#5. 8.991
#6. 8.960
#7. 8.627
.
.
.
#17. 8.502

So if you want a comparison for a c147 you can do a "-psearch fast" on 43^137-1.

Actually, its easier to just estimate. If the leading coefficient of the best poly found is less than 1/N of the maximum coefficient searched in your -wide job, then it would have also been found by -psearch fast. Do you still have your .p file? With that we can also find out exactly how good the best poly would have been with -fast.

In the c120 I tried, the best poly found had a small leading coefficient - and so was the same with -fast and -wide. With this small dataset at least, using -fast seems to be the way to go.

For jobs bigger than, say, c150, that may not be true. But at that level one might be better off running manually, test sieving, etc.

[bsquared]

Just posted another bugfix - this one is not as critical as the last.

A user noticed that occasionally mpqs would fail to find factors. This turned out to be caused by a bug in my integer sqrt code. Should be fixed now in version 1.26.3.

[lorgix]

Originally Posted by bsquared

Actually, its easier to just estimate.

If that wasn't the case people wouldn't use estimates.

I just sent you the file so you can have a look.

[bsquared]

Originally Posted by lorgix

If that wasn't the case people wouldn't use estimates.

I just sent you the file so you can have a look.

True :)

How many threads did you run that on?

[lorgix]

Originally Posted by bsquared

True :)

How many threads did you run that on?

.. I knew I forgot something.. 4 threads.

Don't know if it matters in this case but that's two physical cores with HT.

Might be interesting to look at the score-rank vs. leading coefficient.

[bsquared]

Ok, so assuming that -wide searched ~3x more coefficients (further assuming that hyperthreads don't give a linear speedup), a -fast search would have turned up the 9.019e-012 poly, but neither of the 9.2x polys.

I haven't tested, but in this case again I doubt "-psearch wide" gave a sufficiently better poly to offset the extra time spent looking for it.

attached is a graph of leading coefficient vs. score

[lorgix]

For all I know the optimal time spent on poly search might be less than the regular.

Would be nice if we could find out though.

Nice plot! Looks largely random..

Maybe log-axis, remove everything <8e-12 etc. would make it more interesting.

p.s. Based on the plot; seems like a more thorough search over a smaller area would be a better use of the time.

[bchaffin]

On a related note, I've wondered recently if it's possible to predict what a "good" poly is for a given composite, and set some threshold. If you score a very lucky poly early on, maybe it would be best just to quit searching and use it. Maybe I'll dig through my old gnfs logs when I find some time... It seems like a good poly score is dependent only on the size of the composite, but is it more complicated than that?

[bsquared]

Originally Posted by bchaffin

On a related note, I've wondered recently if it's possible to predict what a "good" poly is for a given composite, and set some threshold. If you score a very lucky poly early on, maybe it would be best just to quit searching and use it. Maybe I'll dig through my old gnfs logs when I find some time... It seems like a good poly score is dependent only on the size of the composite, but is it more complicated than that?

There may be second order complications that I don't know about, but its pretty clear that there is a solid relationship between poly score and size of composite. If we fit a curve to enough data points and picked something at +2sigma or so for a threshold that might be good enough. At least for smaller jobs. For larger jobs where the difference between a 2 sigma poly and a 5 sigma poly means days or weeks of sieving savings, then that's different.

It seems many people have their own private collections of NFS statistics. Does anyone have a function relating composite size with combined poly score handy along with an idea of size of variations about that "normal line"?

[bsquared]

It's one of those days...

Just posted another (relatively minor) bug fix. Also related to mpqs occasionally not finding factors.

Now at version 1.26.4