Hmm... yes, that's a problem.

Could you zip up all the files (logs, job file, data, etc.) and post it here or email it to me?

[QUOTE=Dubslow;326249]Hmm... yes, that's a problem.

Could you zip up all the files (logs, job file, data, etc.) and post it here or email it to me?[/QUOTE]

Here you are.

[QUOTE=pinhodecarlos;326247]Thank you but that doesn't work and I already gave up on this number. Nothing works. In the nfs.job the N is 1 instead of the composite...lot's of bugs.[/QUOTE]

Just a friendly reminder that this code is under active development... what SVN version did you use?

Also, the second argument of the snfs() function is supposed to be the cofactor, not the known factors, which is why N = 1 in your job file. But ggnfs doesn't really care about that and the job should resume/finish just fine (it did for me).

Dubslow's suggestion is the way to proceed for now... I've done the same thing for dozens of other numbers.

Using your provided files, and the series of commands Dubslow provided, I decided to go ahead and complete your test. Here are the factors:
[CODE]P51 = 117293061923671042882204412853534453603984043895353
P74 = 44924296318697022588016532581184229039193875022231759023985790016680088443[/CODE]

Thanks for the test case.

Just a quick something I spotted in the code. The approx_norms() function in snfs.c calls the msieve eval_poly() from msieve, but passes doubles instead of an int64 and uint32. (One nice feature of a C++ compile is to automatically catch those prototype mismatches.:smile:)

Cheers,

Jonathan

[QUOTE=jcrombie;329260]Just a quick something I spotted in the code. The approx_norms() function in snfs.c calls the msieve eval_poly() from msieve, but passes doubles instead of an int64 and uint32. (One nice feature of a C++ compile is to automatically catch those prototype mismatches.:smile:)

Cheers,

Jonathan[/QUOTE]

Thanks! I'll fix it.

If you try the C build with -Wconversion you'll know why I don't have it on by default [SIZE="1"](head in sand)[/SIZE] :smile:

YAFU 1.34, in filtering stage I've got an error "filtering failed to read polynomials". The same problem with v.1.33

My nfs.job is:
[CODE]n: 1025350232777767894657857694224037906084707953452549927614176139794019761184051887773588580834083860417243760161496256204277649426690598247446485244284214565467839
m: 1000000000000000000000000000000000000
deg: 5
c5: 11
c0: -5
skew: 0.85
# Murphy_E = 1.165e-10
type: snfs
lss: 1
rlim: 7300000
alim: 7300000
lpbr: 28
lpba: 28
mfbr: 53
mfba: 53
rlambda: 2.5
alambda: 2.5
size: 180[/CODE]Command used to run factorization:
[CODE]./yafu "nfs(1025350232777767894657857694224037906084707953452549927614176139794019761184051887773588580834083860417243760161496256204277649426690598247446485244284214565467839)" -siever 13 -r[/CODE]

[QUOTE=unconnected;329424]YAFU 1.34, in filtering stage I've got an error "filtering failed to read polynomials". The same problem with v.1.33

My nfs.job is:
[CODE]n: 1025350232777767894657857694224037906084707953452549927614176139794019761184051887773588580834083860417243760161496256204277649426690598247446485244284214565467839
m: 1000000000000000000000000000000000000
deg: 5
c5: 11
c0: -5
skew: 0.85
# Murphy_E = 1.165e-10
type: snfs
lss: 1
rlim: 7300000
alim: 7300000
lpbr: 28
lpba: 28
mfbr: 53
mfba: 53
rlambda: 2.5
alambda: 2.5
size: 180[/CODE]Command used to run factorization:
[CODE]./yafu "nfs(1025350232777767894657857694224037906084707953452549927614176139794019761184051887773588580834083860417243760161496256204277649426690598247446485244284214565467839)" -siever 13 -r[/CODE][/QUOTE]

Msieve filtering (and probably other post-processing steps) also requires a nfs.fb file. Since it looks like you supplied your own polynomial, the .fb file may not have been created.

It would look like this for your input:
[CODE]
N 1025350232777767894657857694224037906084707953452549927614176139794019761184051887773588580834083860417243760161496256204277649426690598247446485244284214565467839
A5 11
A0 -5
R1 -1
R0 1000000000000000000000000000000000000[/CODE]

Also, I'm not sure what the lss: line is in your .job file... but apparently ggnfs is ok with it.

This SNFS-poly was taken from near-repdigit factorization project ([url]http://hpcgi2.nifty.com/m_kamada/f/c.cgi?q=73333_179[/url]) and I simply added "size: 180" at the end.
It seems that YAFU creates nfs.fb by itself, but without the R0 and R1 parameters in it.

[QUOTE=unconnected;329450]This SNFS-poly was taken from near-repdigit factorization project ([url]http://hpcgi2.nifty.com/m_kamada/f/c.cgi?q=73333_179[/url]) and I simply added "size: 180" at the end.
It seems that YAFU creates nfs.fb by itself, but without the R0 and R1 parameters in it.[/QUOTE]

Ah, yes, yafu left R0 and R1 out of the .fb because they were not in the .job. I guess that ggnfs can use m: instead of Y1: Y0: for the rational poly, but msieve cannot. I think it should work if you add R0 and R1 to the .fb.

If you use yafu revisions 242-[url=http://yafu.svn.sourceforge.net/viewvc/yafu/trunk/factor/nfs/nfs_filemanip.c?r1=275&r2=282]282[/url] it will convert the m just fine :razz:

[QUOTE=Dubslow;329453]If you use yafu revisions 242-[url=http://yafu.svn.sourceforge.net/viewvc/yafu/trunk/factor/nfs/nfs_filemanip.c?r1=275&r2=282]282[/url] it will convert the m just fine :razz:[/QUOTE]

Which is great, except for if there is *also* a Y0/Y1 in the file :) Then you get two copies of R0 R1.