New polynomial finder discussion

[10metreh]

I am testing the sieving. I have discovered that v1.39b's sieving does not carry on from where it left off, it restarts from the beginning! What is even weirder is that it does not do the poly finding all over again! What is causing this?

[joral]

10metreh:

I've seen that if there is a msieve.fb file (or other name if you specify the name) it won't search for a new poly.

[jasonp]

The sieving does remember where it left off, but you have to perform an orderly shutdown for the library to write a memo to itself. Hitting ctrl-C once will cause an orderly shutdown, but in windows ctrl-C twice will cause an immediate exit. This is a failing in Windows' emulation of unix signals; on unix systems you cannot do other than an orderly shutdown, without killing the process. If the library finds a generated polynomial for the input number then it will not perform polynomial selection again.

You should not be using msieve's line siever anyway; the lattice siever in GGNFS is over 5x faster, and if you will be doing NFS a lot then it's definitely worth the learning curve to figure out how to use it.

[10metreh]

Originally Posted by jasonp

to figure out how to use it.

Highlighting the exact problem I was having.

[Batalov]

Here's a bit that some even seasoned pol51 users don't know.

There are -F, -f and -A parameters to pol51opt - these are the intended rlim/alim and sieving area. If you don't set these, the defaults are 10e6, 5e6 and 1e16, which is fine for a medium project (and probably an overkill for a small project!). For GNFS-160, I've played with these, and I've got another 5% sieiving speed increase for the paricular rlim/alim's which I've chosen by that time (50e6).

Reading the source is Schlendrian-ly exciting sometimes.

P.S. Don't ask me what Schlendrian means... but it's all over the pol51's source...

[jasonp]

I wondered about Schlendrian too; based on the output of google translate it means approximately "get the hell out"

I think that those undocumented fields are only used in stage2 of pol51, in the root sieve. From memory, they're only there to expand or contract the search space where the root sieve looks for polynomials with good root properties. Unfortunately, the size of the space is capped at a fairly small value, and the source is really not designed to handle big, variably-shaped sieving regions. In fact, it's entirely possible that any speedup people are seeing from using msieve with the new polynomial finder is just a consequence of the root sieve in the new code being much better.

PS: The record for incredibly good root score belongs to a weekend-long run for RSA140. Can you believe an alpha of -8.40?

PPS: Ben, the E scores between pol51 and msieve have different scaling. For a C150 the msieve score is expected to be smaller by a factor of 513, so the poly you found is already marginally better than the output of pol5

[dleclair]

PS: The record for incredibly good root score belongs to a weekend-long run for RSA140. Can you believe an alpha of -8.40?

Ah rats, I was hoping the -8.20 that got for a C148 today would be newsworthy.

-Don Leclair

[schickel]

Originally Posted by 10metreh

Highlighting the exact problem I was having.

10metreh, if you need some pointers getting started with GGNFS, feel free to PM me and maybe I can help. Mostly it's a matter of getting the script set up and then it's fire-and-forget as far as running single jobs.

[akruppa]

"Schlendrian" moved to http://www.mersenneforum.org/showthread.php?t=11028

Alex

[ATH]

Tried it on a C128:
searching leading coefficients from 30357 to 90288
deadline: 100 seconds per coefficient
.
.
polynomial selection complete
R0: -3118618624228121240836480
R1: 102846405002957
A0: -373191664183440699075927408266733
A1: 5115579908996970704322501293
A2: -725332801096315655694
A3: -40760606623946118
A4: 7632532192
A5: 39960
size score = 2.246730e-013, Murphy alpha = -7.262002, combined = 2.528327e-012
generating factor base


I'd like to test what GGNFS finds, what is the options for pol51m0b.exe and pol51m0n.exe to test the same coefficients?

[Phil MjX]

Hi !

I am trying to find a good poly for a c141.

Compared to v1.38, the alpha values found for the polys by v1.39 are much better but the norms are worse (as a comparison, some xx.e18 (1.38) versus rare xx.e19 and many xx.e20 with excellent alpha (v1.39))...
So the global score of good polys popping out there are roughly equal (except for a lucky one)...

Should it be possible that the criterions for the norms are too relaxed with the new approach and that another lower limit would speed up things a lot ?

Regards

Philippe

PS : as a bonus question : is the multiplier 60 better than another like 144 or 720 ? Early versions of ggnfs poly selection tool used huge smooth multipliers (of several thousands) in a strange strategy of resieving promising intervals with smaller multiplier...