[QUOTE=smh;162665]Setting num_cpu in the script only determines the number of threads msieve uses to solve the matrix.[/QUOTE]

You must be running an old version of the script because it does that and also sets the number of sievers to use as well in the latest SVN build of factMsieve.pl which you can find here: [url]http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/tests/[/url]

Jeff.

[QUOTE=tmorrow;162671]For those lazy (like me :-) the conversion from msieve.fb to example.poly can be automated with sed/awk or with perl scripts, e.g. in your webpage example:
[/QUOTE]

Thanks for the script, I will add that as well.

[QUOTE=jasonp;162685]When the input is larger (~140 digits and up) I don't trust either the polynomial selection parameters or the optimization in msieve to find a better polynomial all the time; it has done so, but I see a lot of work needed for larger jobs.[/QUOTE]

So Jason, would you suggest that I recommend that people use pol51 for jobs larger than 140 digits. Is that going to be true with the 1.40 release as well?

Jeff.

If you are writing an introductory guide then go ahead and recommend a safe default for everybody. I'd be fine with not using msieve at all through the perl script; people here have enough experience to know what to do if they need extra polynomial oomph. The sieving speedup for small jobs is not terribly big anyway.

v1.40 will have many changes in stage 2 (the pol51opt part of things) but I have barely changed stage 1 at all, and this will still need major optimizations before it becomes reliably competitive with pol5.

Ok I think what I will do for now then is to modify the guide to show an example using pol51 for polynomial generation so it has less steps and is simpler for everyone.

But I will also put a link on the page to instructions on how to use msieve for polynomial generation including the handy script from tmorrow in case pol51 fails or they want to have more optimal polys for smaller files.

Thanks for everyone's suggestions, I hope to have an updated version in the near future.

Ok I have updated the main part of the guide here:
[url]http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html[/url]

and the sub-guide for msieve poly selection is here:
[url]http://gilchrist.ca/jeff/factoring/nfs_msieve_poly_guide.html[/url]

Hopefully it all meshes together nicely now.

Jeff.

[quote=Jeff Gilchrist;162596]I wished the same thing so I figured I should make it easier for the next group of people starting. Thanks for the comments, if you could track down the URL for the linux binaries and the SNFS details I will add them.

I also forgot to add a link to the GGNFS message board if people want more info.[/quote]

ok, after much frustration (a pox on the forum search engine!), here are links to the snfs polynomial generation programs that I know about:

For Homogenous Cunninghams
[URL]http://www.mersenneforum.org/showthread.php?t=8739[/URL]

For Cunninghams:
[URL]http://home.in.tum.de/~kruppa/numbth.html[/URL]

And I think there is one for XYYX numbers in thats groups' yahoo mailing list.

And here are some links to 64 bit optimized lattice siever binaries (opteron or core2):
[URL]http://www.mersenneforum.org/showpost.php?p=126546&postcount=23[/URL]

[QUOTE=bsquared;163023]ok, after much frustration (a pox on the forum search engine!), here are links to the snfs polynomial generation programs that I know about:[/QUOTE]

Thanks very much, I have updated the guide with the links.

Jeff.

I have found an annoying bug in the factMsieve.pl that shows the divisors as being 1 more digit than they really are. Take C131_106_87 as an example, the msieve output is:

[CODE]Sun Feb 22 21:37:50 2009 multiply complete, coefficients have about 83.63 million bits
Sun Feb 22 21:37:52 2009 initial square root is modulo 1006739
Sun Feb 22 21:42:20 2009 prp62 factor: 79961052113534129805009168985584938017201796671547330986184689
Sun Feb 22 21:42:20 2009 prp69 factor: 863509555966817212628874398558741301013796755368031305269361965375077
Sun Feb 22 21:42:20 2009 elapsed time 00:08:33
[/CODE]

The script reads in that data and outputs:

[CODE]Number: C131_106_87
N=69047132605197387428514937682610265456943664752456696963177343638566252052982783316890351486357829680653130018807198946259079596053
( 131 digits)
Divisors found:
r1=79961052113534129805009168985584938017201796671547330986184689
(pp63)
r2=863509555966817212628874398558741301013796755368031305269361965375077
(pp70)
[/CODE]

You can see that the real value is 62 and 69, but the final report from the script shows 63 and 70. It always seems to be off by 1.

The actual perl code that prints that info is:

[CODE]# Sort ascending numerically
@DIVISORS = sort {$a <=> $b} (@DIVISORS);
$r = 1;
while($_ = shift @DIVISORS) {
printf(" r%d=%s (pp%d)\n", $r++, $_, length($_));
}
[/CODE]

So it is just using the built-in length() function but I'm guessing the data it reads in must contain an extra space or some other data. I'm not a perl coder so I'm not sure the best way to fix this problem. Any takers?

Jeff.

[QUOTE=Jeff Gilchrist;163656]I have found an annoying bug in the factMsieve.pl that shows the divisors as being 1 more digit than they really are.[/QUOTE]

My guess is that this is running on Windows and picking up the \r\n line endings; try adding a line "s/[^0-9]//g;" after "while($_ = shift @DIVISORS) {" and see if that helps.

[QUOTE=fivemack;163659]My guess is that this is running on Windows and picking up the \r\n line endings; try adding a line "s/[^0-9]//g;" after "while($_ = shift @DIVISORS) {" and see if that helps.[/QUOTE]

Thanks, I will try that.