[QUOTE=R.D. Silverman;116486]Actually, relations do NOT accumulate linearly for the lattice sieve.
As the special-q's get larger, the yield rate drops.
[/QUOTE]

The yield rate doesn't seem to drop off very fast with q. For a 143-digit GNFS job that I've got lying around, I'm getting ~115000 relations from the special-Qs in a range of size 50,000 around n=18 million, and ~90000 around n=36 million. The factor base limit is 18 million and the large-prime limit 2^29.

Most of this is an actual effect of special-Q size rather than of the falling-off of the number of primes in an interval; the yield per special-Q, for a quintic, has a really odd trimodal distribution (attached; I presume the Galois theory is to blame), and I see ~200 relations per good-Q around 18 million and ~160 around 36 million.

A plot of q against {relation count * q^0.3} looks quite flat in this range, though that transformation doesn't make the peaks in the histogram much sharper (graph in next entry)

Here are histograms of rels-per-Q and 'scaled rels'-per-Q

And here's a graph of the number of relations in a 50,000-Q range against Q

[QUOTE=frmky;116539]Jason,

On a very large job (5541360 x 5549765 with weight 478981149 (avg 86.31/col)), I got "lanczos error: not all columns used". Did I just get unlucky, or is this a sign of something more serious? Here's the log:
[/QUOTE]
Very often this happens in the last Lanczos iteration, and it appears harmless in that case so I modified the code to continue in this case. 86190 iterations are not enough to exhaust the dimension of the matrix so the failure happened near but not at the end of the run. My guess is that you are just unlucky (which sucks when the run has taken this long).

[QUOTE=roger;116538]Question: Msieve is limited to 125 digits because it is not feasible to factor larger composites. What is the threshold for msieve vs gnfs (the -n option)?

I have a small list of composites I've factored to calculate how long new factorizations will take, but I've never used the -n option for any of them.

I have two composites waiting at the moment, a C120 with 2000+ curves ECM done, and a C122 with around 1700 curves ECM. If no factor is found by ~curve 2500, I guess I'll try msieve. Any opinions on that?

Thanks![/QUOTE]
I highly recommend learning how to use GGNFS for these numbers. Msieve's NFS module will work on them but it will take at least 10x as long (i.e. 10 weeks instead of 1 week).

QS and NFS both use the same multiple precision code, so either one can handle very large numbers. However, using the QS code for inputs > 105 to 110 digits is still not a good idea.

[QUOTE]I highly recommend learning how to use GGNFS for these numbers. Msieve's NFS module will work on them but it will take at least 10x as long (i.e. 10 weeks instead of 1 week).[/QUOTE]

Is there a website with a walk through? And how is it compiled? Last time I tried, it didn't work, but I can't remember why. A win32 or .exe is best for me with very limited programming knowledge.

Thanks!!

[QUOTE=jasonp;116556]86190 iterations are not enough to exhaust the dimension of the matrix so the failure happened near but not at the end of the run.[/QUOTE]
Scratch that, it's possible that this was a failure on the last Lanczos iteration. I could swear I modified the code to ignore failures when this happens, I guess I was wrong.

Roger, ask the GGNFS mailing list, [email]ggnfs@yahoogroups.com[/email], for advice. The archives are at [url]groups.yahoo.com/group/ggnfs[/url]. Getting set up may not be easy, but once everything is in place factoring a number is one cygwin command line, just like msieve

[QUOTE=jasonp;116568]Scratch that, it's possible that this was a failure on the last Lanczos iteration. I could swear I modified the code to ignore failures when this happens, I guess I was wrong.[/QUOTE]

I'll probably be starting a long run tonight. Would changing the test from
if (dim_solved < n - (64 + POST_LANCZOS_ROWS))

to

if (dim_solved < n - (128 + POST_LANCZOS_ROWS))

be adequate to skip the test on the last iteration without causing any other problems? mask0 seems to be calculated from scratch in the next line anyway.

Greg

[QUOTE=frmky;116651]I'll probably be starting a long run tonight. Would changing the test from
if (dim_solved < n - (64 + POST_LANCZOS_ROWS))

to

if (dim_solved < n - (128 + POST_LANCZOS_ROWS))

be adequate to skip the test on the last iteration without causing any other problems? mask0 seems to be calculated from scratch in the next line anyway.
[/QUOTE]
Yes, I did that with my local sources after your original report. Hopefully that will make the spurious error at the end of the run impossible (of course I thought that the last two times as well :) You may want to log dim_solved, so at least we can see what dim_solved is if/when the failure happens. The next version will have linear agebra checkpoint/restart, so recovery should be easier in the future.

By the way, I owe you a big thank you for all the XYYXF work you've been doing, it was wonderful to check the mailing list every morning and see new big jobs completed. It would also have been nice if one of those jobs got the error and not this monster Cunningham run.

jasonp
you have two GNFS line sieve program (GGNFS and MSIEVE),can you explain the difference? block sieve and bucket sort sieve?


EDIT: Msieve can be downloaded at [URL]http://www.boo.net/~jasonp/qs.html[/URL]

[QUOTE=jasonp;116665]Yes, I did that with my local sources after your original report. Hopefully that will make the spurious error at the end of the run impossible (of course I thought that the last two times as well :) You may want to log dim_solved, so at least we can see what dim_solved is if/when the failure happens.
[/QUOTE]
Actually, more testing shows that the last Lanczos iteration occurs when the number of dimensions solved is slightly less than the number of rows, not the number of colmns. Hence to be completely safe you should only test for failure if dim_solved < (packed_matrix->nrows - 64)

It's up to you if you want to make the change and start over, or take a chance and just keep going.