SNFS factoring for neophytes?

[Batalov]

You may have pasted the poly in a file and somehow ended up without a line break?

(Ben, on your part, you could fix the parser in yafu, too, - to read the last line even if it doesn't have a line break?)


P.S. I've tested both polys before I've posted them - the perl script started working fine on each (I had two more, including a monic), and also I had gotten their alphas and Es. They are all workable.

[bsquared]

Originally Posted by Batalov

You may have pasted the poly in a file and somehow ended up without a line break?

(Ben, on your part, you could fix the parser in yafu, too, - to read the last line even if it doesn't have a line break?)

I didn't know that was the case... thanks, I'll fix it.

[Batalov]

The other possibility would be that Y0 was not pasted into job files at all. Twice.

I don't know either. I admit that I don't have the latest source and even in the one I have, I haven't looked. It was just a wild speculation.

[CRGreathouse]

Originally Posted by Batalov

You may have pasted the poly in a file and somehow ended up without a line break?

That seems to be it. yafu seems to be processing it now.

Thanks, everyone! No major issues, but enough minor issues that I doubt I would have figured it out on my own.

Edit: Wait, it looks like it's doing GNFS:

./yafu-linux64 "nfs(84^84-83^83)" -job snfs.job -threads 2


nfs: commencing nfs on c162: 434052638949540480062453005064516466387568940273504907959561408643897140840774339200963955774565218462487550271836485609508404988323997310781276887844297986477749
nfs: commencing polynomial search over range: 1 - 251
nfs: commencing polynomial search over range: 251 - 501
deadline: 800 CPU-seconds per coefficient
deadline: 800 CPU-seconds per coefficient
coeff 252 specialq 1 - 522520 other 252821 - 606770
coeff 12 specialq 1 - 126201 other 379411 - 910586
aprogs: 34208 entries, 48368 roots
aprogs: 47746 entries, 66014 roots
hashtable: 65536 entries,  1.00 MB
coeff 24 specialq 1 - 174400 other 345917 - 830200
aprogs: 43588 entries, 57400 roots
hashtable: 65536 entries,  1.00 MB
coeff 264 specialq 1 - 533986 other 251258 - 603019
aprogs: 32789 entries, 40693 roots
hashtable: 65536 entries,  1.00 MB
coeff 36 specialq 1 - 210727 other 327713 - 786511
aprogs: 42250 entries, 58430 roots
hashtable: 32768 entries,  0.50 MB
coeff 276 specialq 1 - 545179 other 249773 - 599455
aprogs: 33251 entries, 44103 roots

Did I do something wrong?

[bsquared]

Hard to say, but probably not.

Your command line "Just Works" for me, and it immediately starts sieving. Not sure what the issue is.

Is this the latest version of yafu (1.33)?

Sorry for all of the runaround here. The .pl/.py scripts are probably more stable, but I appreciate you running these tests with yafu - its the only way it'll get better!

[Batalov]

Also, to remove any possible effects of the state (which is preserved in the files sitting around in the directory that you are using), try making a new clean one, copy only snfs.job there, cd there and retry.

gnfs-162 will take (relatively) ages, abort it!

[Batalov]

I was able to foil yafu's evil plans to factor this number. ;-)

On Windows (for the fun of it):
I've downloaded the latest version from SF, planted the snfs.job (without a linebreak in the last line) and started. Lines were added to snfs.job and rlim stuck to the Y0 value! ...and the whole thing failed. Well, I don't have win binaries for the siever, so...

On Linux (moved the same folder):
added linebreak before rlim, edited yafu.ini, and ...off it went just fine.

[CRGreathouse]

Originally Posted by Batalov

Also, to remove any possible effects of the state (which is preserved in the files sitting around in the directory that you are using), try making a new clean one, copy only snfs.job there, cd there and retry.

gnfs-162 will take (relatively) ages, abort it!

Did that, ran yafu from the new directory. It still ran GNFS as far as I can tell. Here's the file:

cat snfs.job 
n: 1279722376069429882674916783738587645201002727982137842794710157040169036868965821113429393
skew: 222414.44
type: snfs
size: NNN
c0: 1055355831583822265944960
c1: 110053741356789971224
c2: 155632423969639
c3: -2603265818
c4: 6120
Y0: -3802720129719817966849
Y1: 269924026471

(there's actually a training newline there, but the forum strips it out) and the log

cat factor.log 
12/04/12 00:56:47 v1.33 @ zed, nfs: commencing gnfs on c162: 434052638949540480062453005064516466387568940273504907959561408643897140840774339200963955774565218462487550271836485609508404988323997310781276887844297986477749
12/04/12 00:56:47 v1.33 @ zed, nfs: commencing poly selection with 2 threads
12/04/12 00:56:47 v1.33 @ zed, nfs: setting deadline of 540000 seconds

I used

../yafu-linux64 "nfs(84^84-83^83)" -job snfs.job -threads 2

[LaurV]

Do you have something like a "-R" somewhere, in the ini file? The number you are trying to factor in the poly is not 162 digits, but 93 digits (it is not the same n:....), does it has some other factors removed? yafu considers it a different thing. He tries gnfs of the C162. Try supplying the number directly, instead of the power expression (!?)

Edit: took yafu 1.33 from sourceforge, took the poly in post #6, used exactly your command line, without specifying any -r, it is crunching:
(very slow core2 duo, winXP_32bits)

nfs: checking for data file
nfs: commencing nfs on c162: 434052638949540480062453005064516466387568940273504
90795956140864389714084077433920096395577456521846248755027183648560950840498832
3997310781276887844297986477749
nfs: continuing with sieving - could not determine last special q; using default
 startq
nfs: commencing rational side lattice sieving over range: 2580000 - 2660000
nfs: commencing rational side lattice sieving over range: 2500000 - 2580000
Warning: Ignoring input line:
size: 162

 Warning:  lowering FB_bound to 2499999.
Warning: Ignoring input line:
size: 162

 Warning:  lowering FB_bound to 2579999.
total yield: 8779, q=2581933 (0.01450 sec/rel)

[CRGreathouse]

Oh... copied the wrong poly. It's working now.

[Dubslow]

Originally Posted by Batalov

I was able to foil yafu's evil plans to factor this number. ;-)

On Windows (for the fun of it):
I've downloaded the latest version from SF, planted the snfs.job (without a linebreak in the last line) and started. Lines were added to snfs.job and rlim stuck to the Y0 value! ...and the whole thing failed. Well, I don't have win binaries for the siever, so...

Whoops! I assumed that even the last line has a newline after it. AFAIKnew, every editor appended a newline to the last line.

The solution would be to read the last character in the file, and see if it's a newline or not, and if not, print one. (The more obvious solution would be to print a newline before rlim; the problem there is that's not deterministically the first thing printed, though I'd be surprised if it ever actually wasn't.) I'm not exactly sure off the top of my head how to do that, though I'm sure it's possible.